chore: pin the next release to 1.0.0 via release-as (#72)

## Summary
- #70's graduation commit manually set the manifest to `1.0.0` in the
same commit that also carried a `!` breaking-change marker.
Release-please treated that marker as new unreleased work on top of the
manifest we'd already bumped, computing `1.0.0 + major = 2.0.0` (opened
as #71, closed unmerged - never tagged or released, confirmed via `gh
release list`/`git ls-remote --tags`).
- Adds `"release-as": "1.0.0"` to `.release-please-config.json` so
release-please targets exactly `1.0.0` for its next PR instead of
computing a bump on top of the current manifest value.

## Follow-up
Per release-please's own docs, `release-as` should be removed (or
bumped) once the resulting `chore(main): release 1.0.0` PR merges -
otherwise future runs keep reusing this pin instead of computing normal
semver bumps. Tracking this so it doesn't get forgotten.

## Test plan
- [x] JSON validated
- [x] `actionlint` re-run on `.github/workflows/main.yaml` - unaffected,
still clean
- [x] Confirmed no `v2.0.0` tag/release exists anywhere (`gh release
list`, `git ls-remote --tags origin`)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Author: bougyman

.release-please-config.json

@@ -3,6 +3,7 @@
     ".": {
       "changelog-path": "CHANGELOG.md",
       "release-type": "simple",
+      "release-as": "1.0.0",
       "bump-minor-pre-major": false,
       "bump-patch-for-minor-pre-major": false,
       "draft": false,