[API] Define compatibility and deprecation policy before 1.0

[lrnv]

Scope

Define the compatibility policy needed to stabilize the API before 1.0 and audit current behavior against it.

Topics

• exported names and documented public-but-unexported names;
• constructor signatures, parameter ordering, type parameters, and return-type substitutions;
• result shapes and concrete-versus-abstract return promises;
• exception categories and behavior for unsupported operations;
• keyword names and defaults;
• deprecation periods and migration notes;
• boundaries between public API and internal extension hooks;
• release checklist for identifying accidental API changes.

Acceptance criteria

• a concise compatibility policy is added to the developer documentation;
• candidate breaking changes are inventoried and assigned to focused issues, with 1.0 deferral where appropriate;
• accidental public surface is either documented and retained or deprecated deliberately;
• a release/PR checklist covers exports, signatures, docs, tests, and deprecations;
• no breaking change is made solely as part of this policy issue.