release: cut v1.0.0

Prepare the first public 1.0.0 release and finish the remaining CI hardening work.

Highlights:
- align Python, Rust, WASM, Conda, API, MCP, and docs version metadata to 1.0.0
- promote package metadata to Production/Stable and update stability/versioning docs for the stable series
- move the accumulated Unreleased notes into a dated 1.0.0 changelog section and keep a fresh top-level Unreleased block
- strengthen the changelog checker so it validates a single top-level Unreleased section
- fix the CI/package support mismatch by declaring Python >=3.10 consistently and gating pandas-ta extras to Python 3.12+
- restore Sphinx autodoc compatibility for documented ferro_ta.<module> imports by registering module aliases
- make the TA-Lib benchmark guardrail less flaky by checking median and tail-percentile speedups instead of failing on a single mild outlier
- switch PyPI publishing to OIDC-only trusted publishing and wire the changelog check into the required CI gate
- apply the Ruff-driven cleanup across the Python and test tree and refresh uv/cargo lockfiles

Validated locally:
- python3 scripts/check_changelog.py
- uv run --with ruff ruff check python tests
- uv run --with ruff ruff format --check python tests
- uv lock --check
- sphinx-build -b html docs docs/_build -W --keep-going
- build/install the ferro_ta 1.0.0 wheel successfully

docs/stability.md

@@ -61,9 +61,8 @@ ferro-ta follows [Semantic Versioning 2.0.0]:
 | New indicators, new sub-modules, new features (backward-compatible) | **MINOR** |
 | Bug fixes, performance improvements, docs, dependency bumps | **PATCH** |
 
-The current version (`0.1.x`) is pre-stable — **breaking changes are possible
-in minor releases**.  When the project reaches 1.0.0, the full SemVer
-contract kicks in.
+The current version (`1.x`) is stable. Breaking changes to stable APIs are
+reserved for future **major** releases.
 
 ---
 
@@ -71,7 +70,7 @@ contract kicks in.
 
 Before removing or renaming any **stable** API:
 
-1. The deprecated name/function is kept for at least **one minor release** after
+1. The deprecated name/function is kept until the next **major release** after
    the deprecation notice.
 2. A `DeprecationWarning` is raised when the deprecated API is used.
 3. The deprecation and removal are documented in `CHANGELOG.md` under
@@ -79,8 +78,8 @@ Before removing or renaming any **stable** API:
 
 Example timeline:
 
-- `0.2.0` — `OLD_NAME` deprecated, `DeprecationWarning` added; `NEW_NAME` available.
-- `0.3.0` — `OLD_NAME` removed.
+- `1.1.0` — `OLD_NAME` deprecated, `DeprecationWarning` added; `NEW_NAME` available.
+- `2.0.0` — `OLD_NAME` removed.
 
 ---