policy(adversary): mis-anchoring is never an Observation — semantic-anchor drift must be IMPORTANT or CRITICAL

## Summary

Adversary rubric currently allows semantic-anchor drift (BC citing wrong module/file as Architecture Anchor) to be reported as **Observation** (non-counter-resetting). This delays convergence by at least one round and, in the worst case, ships mis-anchored specs whose consumers can't be trusted to build the right thing.

Related to #327 (fabricated/mis-anchored sub-anchors caught late) but scoped to a distinct case: the anchor **exists** and is grammatically valid, but points at the wrong file (e.g., 10% of orchestration coverage).

## Repro (real cycle)

STORY-6.06.003 Pass-5 F-P5-003-01 (ftc-blue). BC-6.06.003 v1.9 Architecture Anchor row listed `curator_system.gd` as the sole primary orchestration anchor. In reality, 90% of the confrontation-sequence orchestration (evaluate_trigger, on_zone_exit, on_zone4_choice_made, _trigger_confrontation, _resolve_confrontation, _load_confrontation_scene, on_assist_speed_zero, _active_zone_id) lives in the NEW file `confrontation_system.gd` added by the same story.

Pass-5 adversary reported it as **Observation** (severity: OBS). It did not reset the 3-clean counter. But the anchor was materially wrong — the BC as-shipped would have pointed future implementers/reviewers at the wrong module. Only caught because a downstream consistency-validator flagged it separately.

## Root cause

Adversary rubric treats "anchor row is technically populated" as non-critical. But an anchor whose target does not match >50% of the orchestration surface is a **spec fidelity defect**, not a style nit. Its downstream cost is Phase 4/5 rework (holdout-evaluator reads the wrong file, security-reviewer scans the wrong surface).

## Proposed rule

Amend adversary policy rubric:

> **Semantic-anchor drift** — an anchor row (Architecture Anchor, Test Anchor, Signal Anchor, or equivalent) whose target does not cover the majority of the surface being anchored — is **IMPORTANT** minimum. If the mis-anchor would cause a downstream agent (implementer, holdout-evaluator, security-reviewer) to read the wrong file, it is **CRITICAL**.
>
> Rationale: mis-anchoring is a *silent* fidelity defect. It passes lint, passes CI, and only surfaces when a downstream consumer follows the anchor and finds nothing. Do not classify as Observation.

**Detection heuristic (adversary checklist item):** for each anchor row in the BC/ADR under review, grep the actual file for the symbols/functions the BC claims live there. If <50% coverage, flag IMPORTANT. If 0% coverage, flag CRITICAL.

## Cross-reference

Different from #327 (mis-anchored sub-anchors that don't resolve at all). This one is about anchors that **do** resolve but point at the wrong file.

## Provenance

Wave 2 cycle-001 lessons codification, L-W2-02 (ftc-blue Godot project).