fix(devx): let the dispatcher gate's resolver read let/var, guarded by reassignment (#11445)

`declaredInitializers` anchored on `const` alone, so an error code held in a
`let` reduced to nothing: `resolveConstant` answered `null`, the `codehelper`
branch read that as the runtime-value bound, and the site produced NO site and
NO unresolved even when every value was a literal spelled out in the source.

The anchor now reads `const|let|var`, and the mutability it admits is handled
rather than ignored. A mutable binding's initializer is not the set of values it
holds, so reducing it unconditionally would report a value the program may never
stamp — the ALL-OR-NOTHING wrongness #9568 exists to refuse. Three states:

  - never reassigned in the file: reduces exactly as the `const` spelling does;
  - reassigned, with a literal initializer: refused, and REPORTED as unresolved
    (reason `reassigned`) — a code is visibly spelled out and only the
    reassignment stops us claiming the set;
  - reassigned with no literal anywhere: untouched, still the #9460
    runtime-value bound, still silent.

Reassignment detection is file-local, which is complete rather than approximate:
a local cannot be assigned from another file, and ES modules forbid an importer
assigning to an imported binding. It is biased toward over-detection, because a
false positive costs a reduction while a miss costs a wrong site.

Measured tree-wide: sites and unresolved are both byte-identical to before
(21 / 0). Only one `let`-held stamped `code` exists under `packages/**`
(`metadata-protocol/src/protocol.ts`) and its initializer is `null`, so the gap
this closes is latent, not live.

Half 2 (bare reassignment with no declarator) is deliberately not closed.


Claude-Session: https://claude.ai/code/session_015ahemw8RcTgqtxrj15PEZx

Co-authored-by: os-steve <steve@objectstack.ai>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Author: 3 people