feat: opt-in --legacy-severity flag for one-release grace window on check severity remap

Deferred from the **v0.9.6 release review** (CTO + Chaos Gremlin, P2).

## Context

v0.9.6 flips `normalizeSeverity` in `check --checks *`:
- Engine `high` → CLI `error` (was `info`)
- Engine `medium` → CLI `warning` (was `info`)

That's a silent behavior change with no rollout lever — every user who upgrades sees their `check --fail-on error|warning` gates behave correctly for the first time, but from their perspective their CI just started failing on unchanged SQL. This is the intended fix (previously the mapping silently downgraded high-risk injections to info, defeating `--fail-on`), but there's zero migration lever.

## What to do

Ship a one-release grace flag so teams with brittle CI gates can opt back into the pre-0.9.6 mapping while they update their pipelines:

- `--legacy-severity` CLI flag (or `ALTIMATE_CHECK_STRICT=0` env var) that restores the pre-0.9.6 `high → info` mapping
- Emit a deprecation warning per-invocation when the flag/env var is set
- Remove in v0.10.0 or v0.9.8 (2-release deprecation cycle)

## Alternative: hard break, no grace

We may prefer the clean hard-break — accept the migration cost, no legacy mode, better long-term posture. In that case, close this issue as **wontfix** with a note explaining the call. Both options are defensible; we deferred the decision from the release itself.

## Priority

P2. Not blocking any customer today (no complaint filed); this is prophylactic based on the release-review CTO/Gremlin lens.