Add opt-in enforcement/lint for the generated stack rule

[ivklgn]

Rescoped after v0.7.0 — the bin/check-* hooks this issue proposed extending were deleted; hook policy now runs inside the CLI. The guardrail has to land somewhere else.

Problem

/archcore:init seeds a project-stack rule whose imperative is "do not introduce alternative frameworks without an ADR", but nothing enforces it. The rule is context-only: it reaches the agent through session-start and the code-alignment injection, and nothing ever compares a dependency change against it.

What changed

plugins/archcore/bin/ no longer contains doc-quality, alignment, cascade or staleness scripts — since v0.7.0 it ships three pass-through launchers and the policy lives in archcore hooks <host> {session-start,pre-tool-use,post-tool-use} (cli-owns-layers-4-5.adr). So there are two candidate homes, and picking one is part of this issue:

1. CLI pre-tool-use (needs-cli) — advisory fires at the moment a manifest edit is written; matches the "catch it when introduced" intent, but adds manifest parsing to a latency-budgeted path.
2. /archcore:review (plugin-side) — a check in the review flow, which already reads branch changes and already routes drift findings into the actualize track. Cheaper, no budget pressure, but the signal arrives at review time rather than at edit time.

Option 2 is the smaller first step and needs no cross-repo coordination; option 1 can follow if the advisory proves useful.

Expected result

An opt-in / advisory guardrail that warns when a manifest change introduces a framework / persistence / styling choice contradicting the accepted stack rule, with no corresponding ADR.

Impact

Turns the seeded stack rule from passive context into a gentle guardrail, catching architectural drift (e.g. a second HTTP framework) instead of letting it land unremarked.

Proposed approach

• Decide the home (review-side first, per above).
• Ship advisory-only (warn, never block).
• Heuristics for "new framework/persistence/styling without an ADR" derived from the accepted stack rule's own body.

Acceptance criteria

• Adding a dependency that contradicts the stack rule (without an ADR) emits an advisory.
• The guardrail never blocks and is opt-in.

References

Design rationale: .archcore/plugin/zero-content-onboarding-implementation.plan.md and magic-first-day-init.plan.md (both "Out of scope: enforcement"). Post-split context: cli-owns-layers-4-5.adr.md, hooks-validation-system.spec.md. Code: plugins/archcore/skills/review/SKILL.md, plugins/archcore/skills/_shared/grounding/detect-stack.md.