docs(changelog): backfill omitted 0.8.1 and 0.9.0 entries

[zfarrell]

Two shipped releases carried breaking changes recorded only as raw commit subjects, so the changelog never told callers they were affected. Backfills the missing entries; no code changes.

0.9.0 — regen #90 added a required default_schema field to DatabaseSummary, DatabaseDetailResponse, and CreateDatabaseResponse, which changed all three new() signatures. It also added optional default_schema on CreateDatabaseRequest and optional key on three table decls. The only entry was chore(api): exclude datasets from public OpenAPI spec + docs cleanup.

0.8.1 — LoadManagedTableRequest::new(mode, upload_id) became new(mode). This went out in a patch release, which Cargo treats as compatible with 0.8.0 for a 0.x crate, so it could surface on cargo update. The entry was feat(tables): support loading from query results.

Every claim was verified against the v0.8.1 / v0.9.0 tags rather than the PR diffs. Existing raw-subject bullets are left in place so the entries stay traceable to their regens.

[claude]

super nit: (not blocking) The published GitHub Release notes for v0.8.1 and v0.9.0 won't pick these up. .github/workflows/release.yml checks out ref: ${{ env.RELEASE_TAG }} (line 37) and extracts notes from the CHANGELOG at that tag, so a workflow_dispatch re-run for v0.8.1 would re-render the old, pre-backfill section — and make_latest: true (line 78) would additionally re-point "latest" at an old tag. Since the point of the backfill is that affected callers were never told, it's worth editing those two release bodies by hand after merge.

[claude]

Verified every claim against the current source: DatabaseSummary::new(default_catalog, default_schema, id), DatabaseDetailResponse::new(attachments, default_catalog, default_connection_id, default_schema, id), CreateDatabaseResponse::new(default_catalog, default_connection_id, default_schema, id), the optional default_schema on CreateDatabaseRequest, the optional key on AddManagedTableDecl / AddManagedTableRequest / DatabaseDefaultTableDecl, and LoadManagedTableRequest::new(mode) with optional upload_id / result_id. The 0.9.0 attribution matches PR #90's file list (merged 2026-07-15, same day as the tag). Semantics in the new entries match the generated doc comments.

[zfarrell]

Confirmed, and worth sharpening: the hazard isn't only stale notes. make_latest: true (release.yml:78) is unconditional, so a workflow_dispatch re-run for v0.8.1 or v0.9.0 would re-point "latest" from v0.10.0 to that old tag. So the fix must be a manual gh release edit on the two bodies, not a workflow re-run.

Both published bodies currently carry only the raw subjects, so they need the same treatment as the CHANGELOG sections here. Doing that after this merges.

Separately, the unconditional make_latest: true looks like a latent bug worth fixing on its own — any re-run of any old tag silently moves "latest" backwards.