docs: establish security, release, support, and governance readiness

[CompleteDotTech]

Summary

Establishes the security, support, release, and governance readiness surfaces required to publish and maintain Psyche as a protocol relied on by multiple OpenCoven repositories. This is a docs-only change: nine new files, no code, no workflow, no behavior change. Every documented control distinguishes what is current today (cargo-deny, gitleaks, fail-closed wrapper checksums, forward-only migrations) from what is applied at settings time or first exercised at the release rehearsal, so readiness can be verified rather than claimed from file presence.

• SECURITY.md — supported versions/surfaces (main-branch builds only; npm unpublished, gated at G12), private vulnerability reporting route, disclosure expectations (ack ≤5 business days, updates every 14 days, coordinated disclosure ≤90 days), and the ordinary-support boundary.
• SUPPORT.md — public support routes and the reporting contract that keeps secrets, raw prompts, unrestricted terminal output, private repository data, environment dumps, and full personal paths out of public issues.
• .github/CODEOWNERS — protected review for core contracts, store/migrations, Coven boundary, surfaces, conformance, evidence, CI, release, and docs, with the reasoning documented in docs/GOVERNANCE.md.
• .github/PULL_REQUEST_TEMPLATE.md — scope, risk, contract impact, migration, rollback, generated artifacts, tests, and affected consumers.
• .github/ISSUE_TEMPLATE/ — guarded defect and contract/conformance forms; blank issues disabled because unstructured intake is where protected data leaks.
• docs/GOVERNANCE.md — ownership map, branch/ruleset policy (required checks and review applying to maintainers and administrators, no silent bypass), named/time-bounded/auditable emergency changes with restoration and review, and the current dependency-review/secret-scanning/provenance controls aligned with the existing cargo-deny and gitleaks checks.
• docs/RELEASE.md — the release contract: artifact types and the single npm distribution channel, versioning for protocol schema/profile, Rust implementation, npm wrapper, and conformance runner, immutable release metadata (SBOM, provenance, signed digests), packed-artifact verification from a clean install rather than source-relative imports, RC/stable/deprecation/emergency-patch/rollback procedures, support windows and upgrade/downgrade policy (downgrade fails closed on UnsupportedDatabaseVersion), the compatibility matrix with downstream canary evidence, and the one-rehearsal checklist.

Scope

Docs and governance surfaces only: root community-health files, .github/ templates and CODEOWNERS, and docs/. No crate, package, workflow, or script is touched.

Risk

Low: no executable code changes. The main risk is a policy statement that overclaims — every current-state claim is verified against source in this commit (Store::open version refusal, placeholder digest tests, CI check names, deny.toml checks, pack allowlist), and aspirational controls are labeled as such rather than presented as active.

Contract impact

None — the closed v1 registry, error codes, digest computation, and record identity are untouched.

Migration

None — the store schema is untouched; 001_foundation.sql and migrations.rs are unreferenced beyond documenting their existing forward-only behavior.

Rollback

Revert the commit. The files are additive documentation; no data, artifact, or setting is created by this change.

Generated artifacts

None — no fixtures, digests, manifests, or tarballs are generated.

Tests

• YAML structure of the three issue-template files validated (js-yaml parse; unique field ids)
• All relative links across the new docs resolve (scripted check)
• npm --prefix packages/psyche-npm test — 16 pass, 0 fail (repo health; unrelated to the diff)
• cargo fmt / cargo clippy / cargo test — deferred to CI (no Rust toolchain in the authoring environment; the diff contains no Rust)

Affected consumers

None directly. Downstream consumers (coven, adapters) gain documented ownership, reporting, and release-support contracts to bind against once the ruleset is applied.

Issue

Refs OpenCoven#14

Vehicle note: opened in the fork CompleteDotTech/psyche as the CI vehicle — this token cannot write to OpenCoven/psyche. Re-target upstream once write access is restored. Refs OpenCoven#14.

CI note (checkless vehicle): no CI exists on this fork vehicle. Repository Actions is enabled, but the CI workflow (.github/workflows/ci.yml) has never registered or run on CompleteDotTech/psyche — 0 workflow runs since fork creation, 0 check-runs on the head SHA 29aa2e6719837027f310e6cc514b2f9a98a19bfa after ~10 minutes, and PUT /actions/workflows/ci.yml/enable returns 404 (workflow not registered). Upstream CI cannot be exercised from this vehicle because upstream PR creation is 403 for this token. When this PR is re-targeted to OpenCoven/psyche, upstream CI should run there; note that its G2 evidence relationships step currently fails for every substantive PR (it asserts an evidence-only diff and same-repo provenance — see open upstream PRs OpenCoven#15 and OpenCoven#17, which fail identically), so a docs-only PR is expected red on that one step through no fault of its diff.