Backport of the content-integrity fixes from dev (#148, #151 and the VP-9220
guard) onto the 3.830 support line, scoped to what the data loss needs. The
dev-only companions those PRs sit next to — the asset-reference index, the
page-changed re-index event, SyncGroupSettingsToContent, the CopyPageContent
endpoint, UpdateGroup draft-seeding — are deliberately not brought along.

Reported by a customer on Azure SQL: pages opened blank in the designer at
random and days of work were lost. Four defects combined into that.

Writes were not atomic. SaveBinaryAsync blanked the content column in one
autocommitted statement and then appended the payload 8 KB at a time in more
autocommitted statements. Anything that interrupted the sequence — a dropped
connection, a request the client aborted, one of the transient faults Azure SQL
documents as expected — left the page empty for good. The write now runs in a
transaction when the caller has not started one, so an interruption rolls back
and the previous content survives. The body is also drained before the
transaction opens, so a stalled upload fails before the column is touched.

Reads could not tell "never written" from "written and empty". A draft row whose
content column is NULL now reports as having no content, so the reader falls
through to the published page instead of serving a blank 200 over it.

Selection picked the newest row rather than the current one. SavePageContent
creates the draft row and writes its content in a separate step, so in between —
and permanently, after a write that failed — the draft was the newest row with no
content, and it shadowed the published page that still held the work. Selection
is now by status: draft when requested, then published.

Saves that carried no document were written verbatim. An empty or unparsable body
became "deliberately empty" content, which the fall-through cannot rescue because
it is indistinguishable from content the author cleared on purpose; the next
publish then promoted it and deleted the page that still had the content. Such a
body is now refused before the group is touched, so no draft row is stranded
either. Clearing every block stays a legitimate save.

Every content read and write also leaked a DI scope, a DbContext and an open
pooled connection. On Azure SQL that walks into the per-database session limit,
whose errors are exactly the transient faults that used to blank a page — the
leak fed the corruption. The repository now owns that scope and disposes it.

#148 comes along because the base repository hardcoded T-SQL for every provider:
PostgreSQL failed outright and MySQL accepted the blanking statement and then
failed the append, wiping content on every save.

Verified: build clean (TreatWarningsAsErrors), 20 tests green. Both invariants
proven red first — removing the guard fails 7 tests, restoring the newest-row
selection fails 4.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>