Move semantic validation and asset identity planning out of `internal/parser`

[cssbruno]

Summary

internal/parser currently does more than turn source text into a syntax tree. During parsing it also performs semantic policy checks and derives generated-asset identity, including examples such as:

• requiring exported Go handler identifiers;
• enforcing endpoint HTTP-method policy;
• validating fragment target semantics;
• normalizing some route/error metadata;
• calculating component CSS HashKey and ScopeID values and attaching them to AST asset references.

The lowering layer then copies many of these derived values into gwdkir while retaining both raw block bodies and parsed forms.

Why this boundary is risky

A syntax parser should primarily preserve what the author wrote and report grammar/structural errors. Compiler policy and generation planning change for different reasons:

• allowed methods or handler rules may evolve without a grammar change;
• feature availability depends on config and analysis context;
• CSS scope/hash strategy is an output-planning concern;
• LSP, formatter, migration tools, and partial parses benefit from a syntax tree even when semantic declarations are invalid;
• parse-time rejection makes it harder to accumulate consistent semantic diagnostics across files.

Attaching generated hash identity to AST nodes also makes syntax records depend on asset-generation strategy rather than source meaning.

Proposed boundary

Parser

• Recognize declarations and embedded-language blocks.
• Preserve exact values and source spans.
• Report malformed syntax, unmatched delimiters, and structural parse errors.
• Recover enough structure for tooling.

Semantic analysis / compiler validation

• Validate exported handler names and allowed methods.
• Validate fragment targets, route contracts, feature gates, duplicates, and cross-file references.
• Normalize semantic values where needed while retaining source references.

Asset planning

• Compute CSS scope IDs, hash keys, content identities, and output paths from semantic owner IDs plus source/assets.

Parsing an embedded language such as view {} into its own typed syntax model can remain parse work; the concern is semantic policy and target identity, not nested parsing itself.

Acceptance criteria

• ParseSyntax can return a useful AST for syntactically valid declarations even when handler methods, exported-name rules, feature gates, or referenced targets are semantically invalid.
• Endpoint method/export checks are emitted by a shared semantic validation phase used by CLI checks and LSP diagnostics.
• Component CSS scope/hash values are computed outside gwdkast/internal/parser.
• AST asset references describe source-authored asset declarations, not generated output identity.
• Lowering does not need to copy target-specific hash/planning metadata from syntax nodes.
• Diagnostic codes and source spans remain at least as precise as today.
• Formatter and LSP tests cover recovery from semantically invalid but syntactically valid files.
• Architecture documentation states which invariants belong to parsing, semantic analysis, and target planning.