fix(provider): count directive-malformation and enum-increment as syntaxError

[e54-bot]

Summary

Second review follow-up to #578 (after #587). Audited script-invalid and the enum-* codes against their emit sites:

• script-invalid is document-local — all three emit sites judge the directive line's own text: #!postCompileHook without a quoted path (preprocess/directives.rs:105) and a malformed __script__(...) body in #!define (preprocess/macros.rs:141,150). The verdict is about the line's shape, not the script file — matching sibling directive-malformation codes already listed (directive-invalid, define-invalid, macro-invalid). Before this change, #!postCompileHook junk returned {"valid": true} where pre-fix(provider): scope lpp/validateEdits syntaxError to document-local malformation #578 returned syntaxError.
• enum-increment is document-local — EnumCounter::Other keys only on the previous initializer's literal shape inside the same single-file enum block (lower/declarations.rs:246).
• enum-type-without-member stays deferred — enum_visible consults the project-merged declaration table, so a bare name may resolve through a sibling declaration; deferral is now documented explicitly in the allowlist comment.

Test plan

• Three new validate_edits_applies_normative_rules cases (unquoted postCompileHook, malformed __script__, non-numeric enum predecessor) — verified failing without the allowlist entries
• cargo test -p opy-provider --test lpp — 69/69 pass (run locally)
• cargo fmt --all -- --check, cargo clippy -p opy-provider --all-targets -- -D warnings

[Teakowa]

LGTM — emit-site audit holds: all three script-invalid sites judge the directive line's own text, enum-increment needs only the same-block predecessor. enum-type-without-member correctly stays deferred (enum_visible reads the project-merged table). New cases verified failing without the entries.