Module recognizer 

Recognizer implementations for the engine’s strict dispatch path.

Phase-4 PR-2 (T058 + T063) wraps marque-core’s existing strict parser behind the domain-neutral Recognizer trait so crate::Engine::lint dispatches parsing through Arc<dyn Recognizer<S>> instead of instantiating Parser inline. Phase-4 PR-3 will add a DecoderRecognizer alongside this one; both coexist behind the same trait object.

Why this lives in marque-engine, not marque-capco

Constitution VII forbids marque-capco from depending on marque-core. StrictRecognizer wraps marque_core::Parser and produces CapcoMarking values — it therefore needs both chains, and the constitutional dep-graph names marque-engine as the sole convergence crate. The scheme- adapter pattern from Phase 3 stays intact: marque-capco owns CapcoScheme / CapcoMarking; the engine owns dispatch.

Span-offset contract

The Recognizer trait contract is “given bytes, return a Parsed<M> whose internal spans are relative to the input bytes” (foundational-plan “spans are by offset into this buffer”). Rules in marque-capco expect source-relative spans, so the engine shifts token spans after recognize() returns via [shift_token_spans]. That post-processing is the natural seam — the engine is the only code that sees both the full source buffer and the candidate’s source offset.

Zero-candidate = no fabricated marking

On a strict-parse failure the recognizer returns Parsed::Ambiguous { candidates: vec![] } — the zero-candidate form mandated by the trait contract (foundational-plan line 609-612). Callers MUST treat that as “no plausible interpretation,” not as a silently-fabricated marking.

Structs

StrictRecognizer

Strict-path recognizer. Zero false positives by construction — delegates to the existing Parser, which only accepts the CAPCO-2016 canonical grammar.