Publish stability, support, security, and deprecation policies

[codeforester]

Parent: #214

Train position: 21 of 26
Phase: P3 — Ecosystem trust and broad adoption

Problem

The clean-break v2 train needs a precise point at which compatibility promises begin. Broad consumers cannot assess later upgrade, portability, or security risk without supported release windows, deprecation rules, external-command assumptions, a vulnerability process, and a Bash-specific threat model.

Acceptance criteria

• Declare that SemVer compatibility, deprecation windows, and supported-release promises begin with v2.0.0 GA: additive features and fixes remain within 3.x, while breaking stable public changes require v3 or later.
• Identify 0.x and 1.x as historical and unsupported after v2 GA, with no retroactive compatibility promise or pre-v2 deprecation requirement; document the withdrawn July 2026 v2 tag/formula event without treating it as a supported release.
• Add SECURITY.md with private reporting, acknowledgement and response expectations, coordinated disclosure, and supported-version information.
• Publish a threat model covering sourced code, argv, configuration, paths and symlinks, temporary files, deletion, subprocesses, logs and secrets, signals, network retries, imports, vendoring, and release supply chain.
• State Bash, OS, userland, locale, filesystem, privilege, TTY, and optional external-command guarantees and limitations.
• Define release tag, artifact signature or attestation, SBOM, provenance, dependency update, and incident-response policy.
• Map every material guarantee to automated evidence or an explicit caller responsibility and link the policies from the README, docs, issue forms, and releases.
• Ensure support claims cannot diverge from the enforced compatibility matrix or artifact verification results.

Dependencies

• Establish the v2.0.0 release line and enforce trustworthy version invariants #215
• Make command diagnostics secret-safe by construction #217
• Make GitHub API retries bounded and idempotency-aware #218
• Harden cleanup deletion, trap, and resource-unwinding contracts #221
• Standardize public error, status, output, and mutation semantics #224
• Publish a machine-readable API and module manifest #225
• Ship pinned bundle, vendor, update, and verified release workflows #233