docs: define the pre-1.0 stability and deprecation contract

[dgenio]

Progresses #145 (the ROADMAP portion already landed in #276).

What changed

Adds docs/versioning.md defining:

• what counts as supported public API (weaver_kernel.__all__ + explicitly documented public submodules);
• patch/minor/1.0 semantics while pre-1.0;
• a default ≥2-minor deprecation window when compatibility is safe;
• when security/correctness requires a fail-closed break without a deprecation window;
• stricter treatment for stable reason codes, wire artifacts and cross-language contracts;
• integration version/coverage promises as compatibility surfaces;
• the Security Contract itself as a compatibility surface;
• concrete 1.0 readiness criteria;
• a contributor change checklist.

Updates CONTRIBUTING.md so public/security-sensitive changes must identify their compatibility/migration story and must not preserve unsafe behavior solely to avoid a break.

Why

Pre-1.0 should permit deliberate contract evolution, not surprise churn. Security defaults are especially important: a fail-open or invariant-violating behavior should be fixed even when that is breaking, but the migration/release story must be explicit.

Remaining #145 scope

• The public ROADMAP.md + README roadmap link are already complete via docs: define security contract and adoption-gated roadmap #276.
• This PR completes the substantive stability/deprecation-policy requirement.
• GitHub milestone creation is not exposed by the current connected GitHub mutation surface, so I am not pretending that acceptance criterion is complete here; the issue can remain open for that repository-setting/project-management follow-up if desired.

[Copilot]

Pull request overview

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Defines Weaver Kernel’s pre-1.0 stability/deprecation contract and updates contributor guidance so public/security-sensitive changes include an explicit compatibility and migration story.

Changes:

• Added docs/versioning.md to document what counts as public API, pre-1.0 SemVer interpretation, deprecation windows, and security-driven “fail-closed” breaks.
• Updated CONTRIBUTING.md to require explicitly identifying compatibility surfaces (public API, wire/machine contracts, integrations, Security Contract) and to avoid preserving unsafe behavior for compatibility.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
docs/versioning.md	Introduces the project’s stability/deprecation policy, including security- and integration-compatibility expectations.
CONTRIBUTING.md	Adds contributor requirements to consult the policy/contract and document compatibility + migration rationale for breaking or security-sensitive changes.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.