stack-encrypt release: define stable Rust gates and supported conformance versions #1490

Milestone 4 now tracks both API completion and cross-language conformance. Define exactly what blocks the stable Rust release instead of equating every tracked follow-up with a release gate.

Acceptance:

• Record the stable Rust public surface, required profiles/backends, supported engine/SDK/SQL versions and optional capabilities.
• Explicitly classify Python (python: parity with Rust, fixtures, frozen rows, heap hygiene #1393), TypeScript (stack-encrypt conformance: add TypeScript runner and public SDK mapping tests #1479) and packaging (stack-encrypt refactor: finalize crate ownership, naming and coordinated migration #1489) deliverables as required or deferred, with rationale; tracking alone must not settle that choice.
• Use Docs: EQL v4 and Stack Encrypt compatibility policy #1314 for the persisted-data/EQL compatibility policy and publish profile evolution, unknown-version/capability rejection and expected-behavior change rules.
• Add reports and CI lanes for the claimed version matrix, using stack-encrypt conformance: expand fresh cross-language artifact exchange #1478; distinguish hermetic, database, live-provider and cross-version evidence.
• Verify executable API examples, ownership/context guarantees and lifecycle evidence (stack-encrypt conformance: define lifecycle, cleanup and key-I/O requirements #1480); list unresolved limitations honestly.
• Resolve release dependency pins and publication checks applicable to the chosen release scope; select the release version and date explicitly rather than inferring them from the milestone name.

Build on #1470–#1474 and the remaining milestone tasks. Coordinate the semantic corpus and API migration so a Rust refactor does not silently change released Go/storage behavior.

Plan: conformance roadmap and API redesign #1365.