feat: static semantic analysis layer, and one-pass registry-driven lint

[takeokunn]

Implements the five phases of semantic-analysis.md: a read-only semantic
layer beside the syntax tree, the lint-engine rework that lets rules consume
it, and the consumers each phase names.

The motivating example: zero-divisor used to compare atom_text(view) == Some("0"), so it saw (/ x 0) and nothing else. It now sees
(let ((z 0)) (/ x z)), (/ x (- 1 1)), (/ x #x0), and a divisor reached
through a same-file defconstant — while staying silent on anything merely
possible at run time.

What changed

src/domain/lint — one trait, one registry, one pass.
The suite was four hand-maintained parallel arrays (RULES, RULE_DOCS,
FIXABLE_RULES, WARNING_RULES) plus a 1,650-line function calling 134
collectors in sequence, each walking the whole document on its own, with the
matching automatic fixes stranded in the CLI layer. Adding a rule meant ~500
lines across 11 edit sites; it is now one module plus one registry line. The
four constants are derived from that single array at compile time, with const
assertions pinning each derived length.

131 of the 134 rules are reached through an operator index. The three that are
not — duplicate-parameters, duplicate-lambda-list-keyword,
lambda-list-keyword-order — scan only tree.root_children() to reach
top-level definitions, and a per-node check cannot tell that it is looking at a
direct root child. Converting them would silently start matching nested defuns
inside flet/let, which the current behaviour never examines.

	before	after
src/domain/lint_report.rs	3,185 lines	264
src/presentation/cli/lint_report/workflow.rs	2,728 lines	831
lint pass, 1024 forms of ordinary code	124.0 ms	3.60 ms
lint pass, 1024 forms triggering many rules	59.9 ms	3.68 ms

src/domain/semantics — four stacked contexts.
binding inverts lexical_scope's per-symbol query into a per-file table;
value reads literals, folds pure operations, and propagates constants;
typing is a coarse CLHS lattice; project gives a symbol its home package.
Each splits into model / policy / service, and links downward by id
rather than by borrow — a ValueTable holding a &BindingTable would make
them one self-referential struct. RuleContext builds each on first use, so a
run whose rules ask for none pays for none.

Consumers. zero-divisor, parse-integer-default-radix and
constant-if-test read the value table; eq-number-comparison and
eq-char-comparison read the type table, so (eq (length xs) n) is caught
alongside (eq n 5); impact_report reads the project table, so app:run and
test:run stop being one symbol. Every one of them stays silent when the
answer is Unknown.

Verification

• nix flake check — 8/8 (package, clippy, treefmt, actionlint, documentation,
  lint-format-integration, nextest, msrv)
• 3,649 unit + 1,919 integration + 7 doc tests
• inspect lint output is byte-identical to the previous implementation
  across text / JSON / SARIF / --fix-plan / --fix, pinned by a golden test
  generated from the old code before any of this landed. The upgraded rules
  only ever add findings; none were lost.
• The binding table is pinned against lexical_scope by a differential test
  asserting the full partition live = free ⊎ resolved ⊎ definitions over the
  existing fixtures, deriving the live-atom set independently from the reader
  rules so it cannot agree with a bug by construction.
• No existing impact_report test changed: a file with no in-package cannot
  resolve a package, and then the comparison is exactly what it was.

Each of the six commits builds on its own.

Three deliberate departures from the specification

1. LintRule::fix(ctx, finding) was dropped. A LintFinding is a
   projection that has already discarded what a fix needs — the inner span to
   splice, the complement operator to substitute — so findings and fixes are
   produced by the same visit instead.
2. Report order is reconstructed by visit counters, not by span. Sorting by
   (rule, span) looks sufficient but is not: the duplicate-key rules emit
   several findings on one span and the tie has no defined resolution.
3. Opacity was split into three cases. Taken literally, "an unregistered
   head is opaque" makes (/ x z) opaque — CommonLispOperator registers only
   binding forms — which would make the specification's own acceptance
   criterion unreachable. What actually threatens a propagated value is a macro
   expanding into an invisible assignment. A function cannot reach the caller's
   lexical environment at all; a control form evaluates its subforms where they
   are written, so any assignment inside is already collected. Only unknown
   heads stay opaque. The reasoning is in
   semantics/binding/policy/standard_{functions,control_forms}.rs.

Measured, and where to go next

cargo run --example semantic_coverage -- <corpus> reports 15.5% of variable
bindings resolving to a constant. 44% of the misses are bindings with no
initial form — mostly lambda-list parameters, a structural ceiling no loosening
would lift. The actionable 26.6% is opaque scopes, caused by ordinary macros
like handler-case having no registered semantics: one handler-case call
marks its whole enclosing let opaque. Registering a handful of common CL
macros looks like the highest-leverage next step.

The remaining #![allow(dead_code)] in semantics/mod.rs now covers only the
binding table's structural surface — the scope tree and a binding's provenance
— which a scope-aware rule would use and none of today's consumers do.