Document a semver / deprecation policy for the public API

[tschm]

Subcategory: Public API / semver discipline (9→10)

The public surface is clean (two entry points — Portfolio and Data — with _-private internal modules), but there is no documented stability guarantee or deprecation policy telling users what they can rely on across versions.

What to change

• Add a "Versioning & deprecation policy" section to README.md and/or docs/ that states the semver guarantee for the public Portfolio / Data API and the deprecation process (warning window, removal timeline).

Done when

• A deprecation-policy section exists and is linked from the docs, defining the stability guarantee for the Portfolio and Data public surface.

Context: PR #870

[tschm]

Already satisfied on main (landed via #893). A full versioning & deprecation policy exists at docs/STABILITY.md, covering exactly the done-when criteria:

• Stability guarantee for the public surface — names Portfolio and Data (plus Stats, Plots, NativeFrame, NativeFrameOrScalar) as the stable exports, and explicitly marks underscore-prefixed modules/attrs and sub-module import paths as internal/unstable.
• Semver guarantee — patch/minor/major semantics from v1.0.0 onwards.
• Deprecation process — one-minor-version DeprecationWarning window naming the replacement, with a worked removal-timeline table (e.g. deprecate in 1.3.0 → remove in 1.4.0), plus a pre-release (0.x) no-guarantee note.

It's wired into the docs, not orphaned:

• mkdocs nav → Reference → API Stability (mkdocs.yml)
• linked from README.md ("The public API (Portfolio and Data) follows Semantic Versioning … see the API Stability & deprecation policy"), docs/api.md, docs/faq.md, and docs/MIGRATION.md.

Closing as done.