[ngoodger-block]

Why?

This is a cleanup that brings the schema bootstrap in line with how the codebase works today, as asked for by docs/database.md (#8273). Writes are now blocked during community deletion by application admission (begin_community_write_transaction), and that doc's Rule 1 says new tables must not add triggers. But schema/community_write_fence.sql still looped over every table with a community_id column and attached the old fence trigger to it. That meant a new table got a trigger on a fresh database and none on a migrated one, so the two schema paths disagreed and new tenant tables were blocked. The doc says this bootstrap change must land "before the feature, or as the feature's first PR."

What?

Deletes the blanket fence loop and its \i from schema/schema.sql. Existing legacy tables keep their fences through their explicit schema/triggers/ files, so no current table loses its fence and runtime behavior is unchanged. Adds a test that a new community_id table stays unfenced while events and users stay fenced, and updates docs/database.md and ARCHITECTURE.md to match. It stands on its own; the media-sharing PRs (#8451, #8444) are the first to rely on it.

buzz-review-completed