docs: publish release support policy

docs/release-support-policy.md

@@ -0,0 +1,57 @@
+# Release And Support Policy
+
+`geth` is pre-deployment software. Until the first deployment tag, releases are
+pre-releases intended for dogfood and controlled automation only.
+
+## Supported Platforms
+
+Release archives are built for:
+
+- Linux x86_64
+- macOS
+- Windows x86_64
+
+The daemon and control CLI are supported as a single `geth` executable on those
+platforms. Service installation remains user-level only: systemd user units on
+Linux, launchd user agents on macOS, and per-user scheduled tasks on Windows.
+`geth` does not install or require system services.
+
+Overlay interface activation is platform-dependent and may require local host
+entitlements such as Linux `CAP_NET_ADMIN`, macOS network-extension approval, or
+Windows Wintun setup. See `docs/overlay-platforms.md`.
+
+## Compatibility
+
+Before the first deployment tag, breaking changes are allowed when they reduce
+long-term risk and are reflected in `docs/production-readiness-roadmap.md`.
+After the first deployment tag:
+
+- Stable commands and `--json` fields follow `docs/compatibility.md`.
+- Experimental commands may change with a release note and migration path.
+- Prototype commands may change, be replaced, or be removed before a stable
+  guarantee is made.
+- Local SQLite schema changes require ordered migrations and upgrade tests.
+- Signed operation formats must not be changed without a new version or
+  explicit migration behavior.
+
+## Security Updates
+
+Security fixes should be released as soon as practical after validation. The
+project runs CI, RustSec audit, CodeQL, dependency review, and Dependabot, but
+those checks do not replace manual review of Iroh transport, authorization,
+host-opening, and cryptographic boundaries.
+
+Bearer tokens, private SSH keys, and resource secrets must not be copied into
+release artifacts, logs, examples, or support bundles. SSH keys remain local
+admin trust anchors and are never a geth transport fallback.
+
+## Release Checklist
+
+For a tagged release:
+
+- CI must pass formatting, check, tests, and clippy.
+- Security workflows must pass or have an explicit documented exception.
+- Release archives must be built by `.github/workflows/release.yml`.
+- Packaged archives must include README, docs, and license files.
+- Packaged binaries must be smoke-tested from the archive.
+- Any breaking changes must be called out in release notes.