docs: restamp at 1.0.0

[tito]

What

The docs quoted 1.1.0 as the current version in seven places. That number appears in no git tag, no release, and nowhere in the code. This restamps them at 1.0.0, the upcoming release, and fixes the two files that described 1.0.0 as already shipped.

Version strings only. No mike, no version selector, no change to how the site is built or deployed.

File	What
docs/getting-started.md:24,38	expected output of llmproxy version and llmproxy serve
docs/install/binary.md:20,95	the same two output blocks
docs/install/docker.md:10,14	the ghcr.io/greyhavenhq/llmproxy:1.0.0 command a reader copies, and its output
docs/install/upgrades.md:63	the version-pinning advice

Plus the two places that read as though 1.0.0 had already gone out:

• CHANGELOG.md header no longer points at a nonexistent 1.1.0, and the heading is ## [1.0.0] - unreleased rather than dated 2026-08-04. The bullet list underneath is untouched; it describes the feature set accurately whether or not the tag exists.
• CONTRIBUTING.md:142 drops "as history", which carried the same implication.

No Go code changes. The binary version is not hardcoded anywhere: cmd/llmproxy/main.go:30 has version = "dev", stamped at build time from git describe --tags.

Why

Published releases are v0.9.0 and v0.9.1 only, both cut 2026-08-28 against the same CI-prep commit. There is no v1.0.0 tag yet and no plan to release 1.1.0. Documenting a version that will never exist is worse than documenting the one that is coming.

CHANGELOG.md still calls 1.0.0 the "First public release." The 0.9.x tags are release plumbing, never announced, so that reading holds.

Testing

• grep -rn "1\.1\.0" docs/ CHANGELOG.md CONTRIBUTING.md README.md returns nothing.
• mkdocs build --strict passes (the command the Docs workflow runs on any PR touching docs/). No links move, so this was expected to pass unchanged.
• No Go build or test run: nothing under cmd/, internal/ or ui/ changes.

Follow-ups

• The docs now name a tag that does not exist yet. docker.md tells a reader to pull :1.0.0, which will fail with manifest-not-found until v1.0.0 is pushed. Inherent to documenting the upcoming release; it resolves the moment the tag lands. If the gap matters, hold this until v1.0.0 is cut. It is strictly smaller than today's gap, where the docs name 1.1.0 and nothing is planned to release it.
• This will drift again. Nothing checks that the version strings in the docs match the newest tag, which is what produced this task. The cheap fix is a CI grep asserting the two agree. Worth an issue, not worth doing here.