Remove panic/recover control flow from generated identifier construction

[cssbruno]

Priority

Medium

Context

Generated identifier failures are currently represented by generatedIdentifierError, raised with panic, and recovered at top-level app-generator entry points. Unrecognized panic values are rethrown.

The compiler architecture policy otherwise states that malformed IR and generated-output boundary failures should be returned as diagnostics or ordinary errors rather than panics.

Problem

Using panic/recover for expected validation or construction failures obscures function contracts, complicates local reasoning and testing, and risks converting future programmer defects incorrectly or allowing expected errors to escape a boundary that lacks the recovery wrapper.

Proposed direction

Make identifier builders and all dependent source/AST planning functions return explicit errors. Attach endpoint/source context while propagating the error. Keep recovery only at an outer process or request boundary for truly unexpected faults, not as normal generator control flow.

Acceptance criteria

• No non-test appgen path panics for an expected invalid generated identifier.
• Identifier constructors return a typed value plus error.
• Callers propagate errors with page, endpoint, symbol, and source-span context where available.
• recoverGeneratedIdentifierError and generatedIdentifierError are removed.
• Appgen entry points do not require a recovery wrapper for ordinary invalid input.
• Tests cover reserved words, invalid runes, empty identifiers, collisions, and source-derived invalid names through normal error returns.
• A static test or lint check guards the documented no-production-panic policy for compiler/generator packages.
• Truly unexpected panics remain distinguishable from user-authored source errors.

Affected areas

internal/appgen/identifier_errors.go, identifier helpers in generated source planners, appgen public entry points, compiler/generator architecture documentation.