Fix DESIGN §4c body-position source annotation violations (2 blocks)

[gunbai-bot]

Summary

Two // annotation blocks sat inside a declaration body instead of at module-item grain (DESIGN §4c: "The initial .dag realization admits only standalone leading // blocks attached to module-scope declarations; trailing, body, unattached, and block-comment forms refuse until separately modeled"):

• dag/extdeps/systems/nvidia.dag — a note on dgx_spark_catalog_row's memory/memory_bandwidth field derivation, sitting inside the record-literal body.
• dag/test/claim/generated_artifact_drift_test.dag — a note on the third clause of witness_refusal_cause_tokens_are_pairwise_distinct's fold_list cons lambda, sitting inside the fn body.

Both are lifted above their enclosing declaration, with the specific field(s)/clause they describe named explicitly in the new text (since position no longer pins the meaning once it moves), and both keep their original review citations (review 49122, review 49204) verbatim. Per DESIGN §4c, neither was moved into a data _note: String row — that would itself be the "ordinary String declaration whose sole purpose is commentary is misplaced or dead data" anti-pattern the section calls out.

Population closure

A corpus-wide search for indented (body-position) // lines:

find dag src/v2 -name '*.dag' -print0 | xargs -0 grep -nP '^[ \t]+//'

found exactly these 2 blocks (9 lines total) before this change, and zero matches after. No third site exists anywhere in dag/**/*.dag or src/v2/**/*.dag — the violation class is closed to empty, not merely reduced by the two instances noticed.

Why this was invisible on main

The exposing witness, compile_clean_shard_a_exemplar_compile_green (dag/test/claim/dag_compile_clean_shard_a_witness_test.dag), self-compiles the whole corpus regardless of its staged single-file entry stub. It is normally selection-skipped on main pushes:

run 31077711827, job log:
[wet-witness-row-outcome] batch=4 entry=dag/test/claim/dag_compile_clean_shard_a_witness_test.dag
  function=compile_clean_shard_a_exemplar_compile_green outcome=selection-skipped
  detail=skip-before-resolve-fast-path

So the violation had been sitting unexecuted on main, not previously passing. It only surfaced because a downstream PR's (#7905) affected-set happened to select this witness.

Secondary finding: duplicate diagnostic ranges

The compiler reported 9 diagnostic ranges for these 2 blocks (4 overlapping ranges for the nvidia.dag block, 5 for the drift-test block) — a duplicate/overlapping-range artifact per block, not 9 distinct violations. Noted here as a secondary finding, not the headline; not addressed by this PR.

Verification

• gunbc compile --source-root dag --source-root src/v2 --source-root src/v1 --dependency-pool-index primary-precedence --target dag over the full corpus: previously 9 hard diagnostics, now 0.
• compile_clean_shard_a_exemplar_compile_green via claim_batch --wet: now PASS.

Scope note

This is deliberately separate from PR #7905 (session/royal-boar-445, "Refuse autocommit while index has unmerged stages"), which remains blocked on this unrelated CI failure and is left untouched.

🤖 Generated with Claude Code