feat(vba): record each procedure's error policy

[ardelperal]

Task E2 of docs/vba-error-handling-plan.md. Every function node now carries an
errorPolicy object describing how that procedure handles errors.

What it adds

A new classifier src/extraction/vba/errors.ts exporting a four-rule RULES table,
registered in VBA_RULE_TABLES and listed in REQUIRED_DISPATCH_TABLES so the
load-time invariant covers it. The four rules are exactly the ones the issue tabulates —
on-error-label, on-error-resume-next, on-error-reset, line-label — and all four
are scan: 'masked' and requires: 'inside-procedure'.

errorPolicy: {
  protection:       'handler' | 'resume-next' | 'none'
  handlerLabel:     string | null
  handlerStartLine: number | null
  handlerEndLine:   number | null
  behavior:         null          // derived in E3, not guessed here
  handlerCount:     number
  resumeNextOpen:   boolean
  danglingTarget:   string | null
}

Decisions

• Zero new node kinds, zero new edge kinds. Section 4 of the plan rejects a label
  node plus a handles-error edge; this ships the field instead.
• An untargeted label is control flow, not a handler. A label only opens a handler
  region when an On Error GoTo in the same procedure names it. This is the gate that
  keeps 137 corpus labels (siguiente, salir, fin) from producing a confidently
  wrong "this procedure handles errors".
• One boundary detector, three consumers. The procedure body's START is the node the
  procedures pre-walk already emitted (no second PROC_RE); its END is the existing
  PROCEDURE_END_RE that enums-consts.ts's proc-end rule dispatches (no second end
  detector). That is what makes the colon-separated single-line procedure form work here
  for free. Unlike its sibling consumers, this one tests the masked line, so a quoted
  ": End Sub" cannot close a procedure early.
• On Error GoTo -1 is treated as a reset and pinned by a fixture even though it
  appears 0 times in the corpus.
• Agreement with the probe is by construction. LINE_LABEL_RE and NOT_A_LABEL are
  the probe's, not the simplified ^\s*(\w+):\s*$ the issue sketches — the strict sketch
  would have missed every trailing-statement handler (errores: MsgBox "x") and turned
  it into a dangling target. 0 and -1 — and only those two — are resets on both
  sides; every other target, including a numeric VBA line number, is a handler label.

Corpus measurements

Roots: 00_EXPEDIENTES/src, 00_GESTION_RIESGOS/src, HPS_SOLICITUDES/src
(320 .bas/.cls files, 4,817 declared procedures).

protection distribution — the extractor reproduces the probe's census exactly:

protection	npx tsx scripts/vba-coverage-probe.mjs	errorPolicy on the nodes
handler	3774	3774
resume-next	227	227
none	816	816
procedures	4817	4817 (all carry a policy)
procedures with >1 handler	47	47

Node and edge invariant — merge-blocking, and it holds. Same corpus, same script,
run once with this branch's three source files and once with origin/main's:

	before	after
nodes	14649	14649
edges	21361	21361
unresolved references	26613	26613

danglingTarget: non-null for ZERO procedures. The issue's acceptance criterion asks
for exactly 1 and says to name it. There is none, and this is not a miss — §5/E1 of the
plan already records the same divergence: the original hand census counted 1 dangling
GoTo target, and the committed probe reports 0 because it resolves labels per
procedure scope. This classifier agrees with the probe. The corpus does contain a handler
literally named noExiste (1 occurrence), which is defined in its own procedure and is
therefore correctly not dangling — that is very likely the label the original census
mistook for an unresolved target.

resumeNextOpen: 516 procedures. The probe reports 534 Resume Next scopes never
closed; the two count different things (534 scopes spread over 516 procedures), so
they are consistent, not contradictory.

Tests

New __tests__/extraction-vba-error-policy.test.ts — 25 tests, all green. It covers every
acceptance-criteria checkbox that is a unit test: the three protection classes, exact
handlerStartLine/handlerEndLine bracketing, an untargeted label leaving protection: 'none', handlerCount: 2, resumeNextOpen with and without the reset, On Error GoTo -1,
danglingTarget: 'noExiste', per-procedure dangling scope, a Property Get with a handler,
behavior staying null, and both named regression guards — #208 (colon-separated
single-line procedure) and #209 (s = "On Error GoTo errores" sets nothing, plus a real
On Error GoTo sharing a line with a quoted one still counting once). Two tests pin the
zero-node/zero-edge constraint directly.

__tests__/stats-vba-rules.test.ts was updated for the new concern (7 concerns, 23 rules).

Verification

• npx tsc --noEmit — clean.
• New suite: 25/25. vba-coverage-probe-errors 27/27, vba-coverage-probe 16/16, the rule
  table/fields/dispatcher/import-invariant suites, extraction-vba (229), and every other
  *vba* suite — all green (35 files, 472 passed / 1 skipped in the last batch alone).
• Full suite run in batches (a single npx vitest run OOMs on this machine). 21 failures,
  all pre-existing and environmental: Windows EPERM/EBUSY temp-dir removal in
  worktree-detection (15), multi-repo-workspace (2), extraction (2), plus 2 in
  npm-sdk (bundle resolution). None touch VBA extraction.

What I could not verify

• This branch is based on 53a5826, not on the current origin/main (df250a7).
  feat(vba): resolve the table or query named by DLookup and friends #285 landed while this was being written and added its own line to the same
  ### New Features list, so the CHANGELOG.md entries will conflict on merge. The
  resolution is to keep BOTH lines. Nothing else overlaps — feat(vba): resolve the table or query named by DLookup and friends #285 touched
  src/extraction/vba/sql-wrapper.ts and a new test file only.
• Only the three Access projects above were measured; no other VBA corpus was available.
• CI has not run on this branch yet at the time of writing.

Closes #259

🤖 Generated with Claude Code

https://claude.ai/code/session_019gmKKUq1ng5ESk6Qhxu77d