mimosa git-gate: no baseline/stock exemption channel — repos with security-test fixtures get permanently false-blocked

Plugin: mimosa (zcode-plugins-official, protected build 1.0.3) — native git gate (pre-commit / pre-push, 高危阻断 mode).

Problem: The git gate scans staged diffs and blocks commits containing high-severity findings, but there is no supported way to declare the repository's existing (stock) findings as an accepted baseline. For a repository that intentionally ships security-test fixtures (attack samples, process-spawning harness stubs, hardcoded dummy credentials used by negative-control tests), every commit touching those files is blocked — including commits that introduce zero new findings. The only escape hatches are per-line mimosa-ignore comments (intrusive: they mean editing the fixtures themselves) or the env kill-switch MIMOSA_NO_GIT_GATE=1 (bypass, no audit trail).

What I tried:

1. mimosa scan . baseline + backlog import / backlog triage — claims import fine (95 highs, all in pre-existing fixture files), but the gate does not appear to consult the backlog/finding-ledger as a stock baseline.
2. Looked for a project-level exclude/off switch for the gate specifically: policy init (threat-model template) and scan-profiles.json expose no fixture/path exclusion or stock-exemption knob for the gate profile.

Ask: a first-class baseline channel for the git gate, e.g. gate = graded on introduced findings only (diff-attributed against the recorded .mimosa ledger/backlog), or a project-level allowlist of paths/rules the gate should treat as accepted stock. Kill-switch bypasses shouldn't be the only answer for fixture-heavy security repos.

Start by reviewing the native mimosa git gate behavior and the existing .mimosa ledger/backlog flow described in the issue. Compare how scan-profiles.json and policy init represent exclusions or policy controls. Done means the gate can distinguish accepted stock findings from newly introduced findings without relying on per-line ignores or MIMOSA_NO_GIT_GATE=1.