Sweeps: name the concept, not the first use

Two sweeps on 15 September 2026 looked for the coming soon mistake across every repository: a concept named after its first use, one job built twice, or a rule in the wrong home. The first read the code for names and duplicates. The second walked real scenarios (an agency with 20 clients, a clinic, a bilingual school, a newsletter, a booking site, an outage, a module from a third party) through the API, console, renderer, deploy tool and CLI plans.

Every issue below was checked against the default branch before filing.

### Decisions to make first
- [ ] #935 What a tenant is, and where a site lives (4.2.0)
- [ ] #936 The tenant is the unit of operation
- [ ] #937 The API owns the site model and barakoPress renders it (before barakoPress #33)
- [ ] #938 A module declares itself once, per tenant
- [ ] #939 The API is the only home of schema, rules and dry run
- [ ] #940 A content type is a versioned schema
- [ ] #941 What a principal is (4.4.0)
- [ ] #687 One durable work substrate, settled before #831, #833 and #839

### Bugs found on the way
- [ ] #927 ValidationRules are stored and never enforced (4.2.0)
- [ ] #933 Portability import skips validation, entry checks and lifecycle, and can lower sensitivity (4.2.0)
- [ ] #894 A deactivated tenant keeps serving public content (4.2.0)
- [ ] barako-client#10 ContentStatus is numeric while the API sends names
- [ ] barako-client#6 content types list expects an array the API no longer returns

### barakoCMS
4.2.0: #884, #885, #888, #889, #890, #891, #895, #925, #930
4.3.0: #883, #886, #887, #892, #896, #897, #899, #900, #901, #902, #904, #905, #906, #907, #911, #919, #921, #922, #923, #924, #926, #928, #929, #931, #934
4.4.0: #893, #903, #908, #909, #910, #912, #913, #914, #915, #916, #917, #918, #920, #932
5.0.0: #898
Covered by existing issues: retention sweeps #622, cross-tenant queries #877, rollups #836 with #808, localisation #98 (needs a milestone), OpenAPI baseline #631.

### barakoBrew
1.3.0: BaryoDev/barakoBrew#161, BaryoDev/barakoBrew#163, BaryoDev/barakoBrew#165
1.4.0: BaryoDev/barakoBrew#159, BaryoDev/barakoBrew#160, BaryoDev/barakoBrew#162, BaryoDev/barakoBrew#164, BaryoDev/barakoBrew#166, BaryoDev/barakoBrew#167

### barakoPress
0.5.0: BaryoDev/barakoPress#46, BaryoDev/barakoPress#48, BaryoDev/barakoPress#50, BaryoDev/barakoPress#51, BaryoDev/barakoPress#53, BaryoDev/barakoPress#54, BaryoDev/barakoPress#55
0.6.0: BaryoDev/barakoPress#44, BaryoDev/barakoPress#45, BaryoDev/barakoPress#47, BaryoDev/barakoPress#49, BaryoDev/barakoPress#52, BaryoDev/barakoPress#56
0.7.0: BaryoDev/barakoPress#57
barakoPress 0.4.0 is not published yet. #50 (one secret), #46 (holding message) and #55 (every page rendered per request) are cheaper to settle before it ships than to alias after.

### BaryoVM
0.4.0: BaryoDev/BaryoVM#88, BaryoDev/BaryoVM#89, BaryoDev/BaryoVM#90, BaryoDev/BaryoVM#91, BaryoDev/BaryoVM#92, BaryoDev/BaryoVM#93

### barako-client
BaryoDev/barako-client#6, BaryoDev/barako-client#7, BaryoDev/barako-client#8, BaryoDev/barako-client#9, BaryoDev/barako-client#10

### Plans to amend before code
#835 (sweep as a trigger, see #909), #834 (see #932), #844 (same recipe as BaryoDev/BaryoVM#88), #849 (needs device time, idempotency retention and a viewer session), #562 (output cache belongs with #922 on 4.3.0, not 5.0.0).

Start by reading the prerequisite decisions in #935 through #941 and #687, then review the listed bugs and dependent issues to understand their relationships. Done means the architectural decisions and planned amendments are resolved, with the affected issues providing the concrete implementation work.

Written by the indexing model from the issue text.