process-gap(implementer+adversary): spec-named implementation vehicle silently substituted — vehicle conformance not gated

## Summary

A behavioral contract's minimum-viable clause named a concrete implementation vehicle (a direct-color UI primitive with per-entity tint). The implementer substituted a different node type plus a placeholder-texture approach for legitimate coordinate-space reasons. The substitution was never recorded as a deviation — no deviation note, no equivalence argument, no escalation.

The substituted approach introduced exactly the defect class the specified vehicle was immune to: multiplicative tint over a non-white base texture corrupts hues (the engine's placeholder renders a high-saturation non-neutral color, so a pure-color tint multiplied against it produces a wrong color). The originally specified vehicle applies color directly to a rectangle and is structurally immune to this class. No pipeline gate checks implementation-vehicle conformance against a spec-named vehicle.

## Impact

- The defect was visually undetectable by casual observation (result was near-black on a dark background).
- All standard attestation checks (presence, position, hue class) and a human playtest passed.
- The defect was caught only when an orchestrator-side review applied per-channel pixel arithmetic to rendered output.

## Pattern

When a spec names a concrete implementation vehicle (a node type, a rendering primitive, a specific API call), it often names it for a reason — it is the vehicle that is immune to a known defect class in the problem domain. A substitution may be technically valid for orthogonal reasons while silently inheriting the vulnerability the spec was trying to prevent. Neither the implementer nor subsequent reviewers noticed the vehicle mismatch because no gate asks "does the implementation use what the spec named?"

## Proposed remedies

1. **Deviation contract:** When a behavioral contract names a concrete implementation vehicle, the implementer must either conform or record an explicit deviation with an equivalence argument addressing the defect-class the specified vehicle was designed to prevent.

2. **Adversary lens — vehicle conformance:** The adversarial review rotation should include a "vehicle conformance" check pass: for each BC that names a concrete vehicle, verify the implementation uses that vehicle or that a recorded deviation exists with a complete equivalence argument.

3. **Spec-authoring guidance:** When spec authors name a concrete vehicle, they should annotate why (e.g., "direct-color rectangle required to prevent multiplicative-tint corruption"). This gives the deviation-equivalence argument a specific claim to refute.

## Cross-references

- Related to #327 (AC-anchor integrity) in that both are spec-text citations that survive unverified.
- Related to #419/#427 (spec-diff re-read mandate) in that the substitution occurred without the implementer re-reading the vehicle specification.