adversary policy: detect test name/comment claiming branch coverage that the assertion doesn't actually exercise

## Symptom
During fresh-context adversarial review (Pass 21 lens-1) of a downstream vsdd-factory consumer, a test named `expired_key_non_control_rejected` claimed in its comment to exercise the "expired key" branch in a `CallerKeyRoleActive` function. The test set a future-dated TTL, registered the key with a non-control role, and asserted rejection with E-ADM-009. The assertion did fire — but via the role-check path, NOT via the expiry-check path (the key was still active at lookup time). The expiry branch in `CallerKeyRoleActive` was uncovered, and the test passed.

This survived 20 prior adversarial passes because the test "passes" — assertion succeeds, no exception thrown — but its assertion does not exercise the path it claims.

## Root cause
Adversary policy currently checks for tautological assertions (assert true; assert err != nil with no specifics) but does not check for semantic anchoring: does the test name/comment describe the path that the assertion actually traverses?

## Proposed fix
Add to adversary policy:

> For each test where the name encodes a specific branch ("expired_X_rejected", "after_Y_returns_Z"), trace which code path the assertion actually exercises. If the name claims coverage of branch B but the assertion exits earlier via branch A, flag as semantic-anchoring drift.

Cheap heuristic: for each test, the adversary should be able to articulate "the assertion fires because branch X was taken." If branch X is different from the branch encoded in the test name, that's a finding.

## Severity
LOW-MEDIUM — single test, but pattern likely repeated across the codebase. Bug surface = whatever branches the un-exercised "coverage" purports to protect.