release: 1.0.0 -- the exported Python surface is frozen under semver

Nine current-state surfaces bumped by hand. The classification sweep ran
FIRST, before the first edit: 421 hits on 'v?0.N(.N)' across all tracked
files, each read and sorted current-state vs provenance. Provenance is
untouched -- 'New in v0.4.0', 'measured against 0.3.1', every '0.7.0'
in a code comment or a census candidate name still says what it measured.

The sweep found two surfaces the plan's nine-item list did not name:
README's status BADGE (still 'alpha' -- a version string grep cannot see
it) and ADOPTION-BRIEF's test count, which said 791 against a suite that
runs 792. Both corrected.

pyproject also moves Development Status :: 3 - Alpha -> 5 -
Production/Stable, likewise invisible to a version grep.

CHANGELOG [1.0.0] references [0.3.0] and [0.3.1] for the behaviour
changes rather than repeating them, and carries the freeze point itself:
what is frozen (the exported surface), what is deliberately NOT (all
detection calibration), the three conceded limitations, the one known
open defect (:43), and the runtime-coverage gap -- no external consumer
has run 0.7.0.

No code changed. Per docs/PLAN-v1.md the release gate is the whole suite
green, not a new test: 792 passed, coverage matrix 129/129 + 6/6, exit 0.

CHANGELOG.md

@@ -10,6 +10,58 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 Nothing yet.
 
 
+## [1.0.0] — 2026-08-13
+
+### Changed — the exported Python surface is frozen under semver
+
+No code changed in this release. `1.0.0` is a governance promise, not a claim that
+the library is finished: **no name exported from `llm_ingestion_guard` is removed,
+renamed or given a different meaning without a `2.0.0`.** Measured before the tag,
+the surface has been stable in form since `0.3.4` — four names added, none removed
+or renamed — while behaviour moved across five releases (`0.4.0` … `0.7.0`).
+
+**Detection behaviour is deliberately outside the freeze.** Severities, thresholds,
+lexicon entries and the dispositions they produce are calibration, and calibration
+moves in minor and patch releases. A payload that disposes `WARN` here may dispose
+`FAIL_SECURE` in a later `1.x`; that is a fix, not a break. Assert on the
+disposition your policy requires, not on a severity you observed.
+
+The behaviour changes this freeze rests on are not repeated here — see `[0.3.0]`
+for the active-content gate and the OKF adapter, and `[0.3.1]` for the
+ordinary-link/image calibration that the two consumer promises pin.
+
+### Changed — three limitations are conceded for `1.x` rather than deferred
+
+`docs/LIMITATIONS.md` no longer says "deferred" or "pending" about any of them:
+
+- `Severity` still carries disposition intent on the detection side. Separating
+  *what was seen* from *how bad it is* changes `Finding` and `Severity`, so it is a
+  `2.0.0` change. Read a finding's `id` for the capability.
+- The input-cap asymmetry at `MAX_INPUT_CHARS` is permanent in `1.x`: surfaces that
+  return content raise `OversizeInputError`, surfaces that return findings truncate
+  and emit `active:oversize-input`.
+- The multilingual homoglyph false positive is conceded more narrowly — no fix is
+  promised, but it is calibration, so one may land in any `1.x` release.
+
+`SECURITY.md` carries all three as documented boundaries and states the support
+window for a `1.x` line.
+
+### Known at the freeze, deliberately not blocking it
+
+`docs/LIMITATIONS.md` §`:43` — an OKF block sequence with exactly one key per
+element misparses silently in `okf.import_bundle`, so a pointer can ride through in
+a key the `resource` allowlist never inspects. Closing it tightens what the adapter
+admits: behaviour, not form, and shippable in a `1.x` minor. It is recorded here
+because "we knew, and froze first" is a defensible position and "we forgot" is not.
+
+Runtime coverage at the freeze: `llm-ingestion-okf` has measured `0.3.4` and run a
+`0.3.4`→`0.6.1` differential on its own door across two Python versions;
+`llm-security-commons` differentially tested its independent reconstruction of the
+raw-HTML classifier against ours over 42 probe tags with 0 disagreements. **No
+external consumer has run the `0.7.0` runtime**; the four symbols added since
+`0.3.4` are additive, so a caller that does not invoke them is unaffected.
+
+
 ## [0.7.0] — 2026-08-13
 
 ### Added — `active:raw-html-link`, a click-required carrier class for raw HTML