VSTD 1.2.0: define the supported Python API and deprecation lifecycle

[TimeLordRaps]

Coordinate

VSTD 1.2.0 release-candidate packaging and compatibility policy. This is separate from frozen receipt
wire identifiers and must not redefine previously released bytes.

Target

Define which Python application programming interface (API) surfaces receive semantic
versioning guarantees, including whether the supported boundary is:

• names exported through verifier.__all__;
• the generated top-level reference;
• named submodules;
• or a narrower explicitly enumerated set.

Also define deprecation notice, compatibility duration, removal boundaries, and the
relationship between Python API changes, command-line interface aliases, schemas, and
frozen receipt formats.

Exit criteria

• Consumers can identify supported versus internal Python names from one short policy.
• Deprecations are testable and appear in release notes.
• No Python policy weakens permanent command aliases or frozen wire compatibility.
• Semantic-version claims do not imply standards-body status or external adoption.

[TimeLordRaps]

Implemented in stacked pull request #27 at d941df4.

Evidence:

• docs/API_STABILITY.md defines verifier.__all__ as the supported Python application programming interface boundary, mirrored by the generated top-level reference.
• Direct submodule and underscore imports are internal unless separately published as supported.
• Patch/minor/major compatibility and deprecation/removal rules are explicit; command aliases, schemas, and frozen receipt formats remain separate compatibility surfaces.
• _API_DEPRECATIONS plus __getattr__ makes future deprecations emit testable DeprecationWarning values.
• Tests freeze and resolve all 11 current public exports and exercise the warning path. No current public name was deprecated.
• The full 402-test suite and hosted installed-wheel smoke passed in run 33038825743.

The issue remains open for review and will be resolved by landing #27.