Epic: serve a small static site, a news publisher and a transactional system from one CMS

barakoCMS should fit three shapes of customer without becoming three products: a small static site, a news publisher, and something transactional. They want different things, and the parts they share are the parts we have not built.

## What each one needs that we do not have

**A small static site** wants the CMS out of the request path entirely. Publish, produce files, serve them from a CDN, and never let a reader reach Postgres. We produce no files and every public read hits the database.

**A news publisher** wants a cache it can hold for a long time and clear in a second, structured data so the article is eligible for the placements that carry news traffic, and eventually a way to charge. We cache for 60 seconds and emit no structured data.

**Anything transactional** wants writes that do not silently lose each other, limits so one client cannot spend everyone's capacity, and a live stream that actually delivers. Content has no concurrency control, delivery has no rate limiting, and the event stream reaches only the instance that handled the write.

## What they share

All three want the read path to scale and the write path to be honest about conflict. That is the whole theme. The static site needs it because a CDN is only correct if invalidation is, the publisher needs it because traffic arrives in spikes, and the transactional case needs it because a lost write is worse than a slow one.

## The shape of the work

**The blocker.** The module contract has no pipeline hook, so caching, response caching and rate limiting cannot be modules. They are core or they are nothing. That decision comes first because it decides where five of these live.

**Correctness before performance.** Two of these are things that already lose data or already silently drop events. Those go first, because caching something that is wrong makes it wrong faster.

**Then the read path.** Cache by tag and purge on publish, rather than the 60 second window we have. This subsumes #546 and #549, which are the same problem seen twice.

**Then the shapes.** Static export, build triggers, structured data, metered access. Each one is a customer story that becomes possible once the read path is right.

## Not in here

Things already filed and already covered: #545, #546, #548, #549, #550, #551 on caching and contention; #98 localization; #254 full-text search; #252 taxonomy; #100 image variants and #99 sitemap, both closed. Scheduled publishing already exists in `Features/Content/Schedule`. The field registry already has `money`, `decimal`, `reference` and `geopoint`, so the transactional case does not need new primitives, it needs the write path to be trustworthy.

This is an epic rather than a self-contained change. Start by reading the module contract and the existing `Features/Content/Schedule` implementation, then review #545, #546, #548, #549, #550 and #551 for the already-filed caching and contention work. A concrete child issue should define its entry point, tests, and acceptance criteria before implementation.

Written by the indexing model from the issue text.