Events: publish content events to Google Cloud Pub/Sub

Workflow webhooks send one HTTP call per workflow. When several systems need the same change (a search index, a CDN purge, a data warehouse), each one needs its own workflow and its own endpoint, and barakoCMS has to know about all of them.

Add a module that publishes content events to a message topic, so any number of subscribers read them without barakoCMS knowing they exist.

## Proposal

`BarakoCMS.Events.PubSub` for Google Cloud Pub/Sub. An AWS SNS or EventBridge publisher can follow on the same shape.

- Driven by an async Marten projection or subscription on the event store, the same way `WorkflowProjection` feeds workflow runs, not by `IContentLifecycleHook`. That hook runs before the save, so it would publish writes that later fail to commit.
- Events: `Created`, `Updated`, `Published`, `Deleted` and `transition:{name}`, the names in `WorkflowEvents`.
- Message: event name, content type, content id, tenant, event sequence and time. Data is left out unless asked for per content type, and fields marked sensitive are never included.
- The event sequence is the message's dedupe key, so a subscriber can drop a duplicate. A projection rebuild must not publish the full history again; record what was published, the way `WorkflowRunQueue` checks for an existing run.
- Config: project, topic, content types to include. Authenticate with the platform's service account, never a stored key file.

## Why not now

Webhooks already retry with backoff and cover a single subscriber. Build this when a site has two or more consumers for the same events.

## Cost

Pub/Sub's free tier covers 10 GiB of messages a month. A message is well under 1 KB, so a site would need millions of changes a month to pay.

## Done when

- Publishing an entry puts one message on the topic, checked against the Pub/Sub emulator.
- Rebuilding the projection publishes nothing already published.
- A sensitive field never appears in a message.

Start by tracing the async projection or subscription behind WorkflowProjection and compare its deduplication behavior with WorkflowRunQueue; do not use IContentLifecycleHook. Review WorkflowEvents and the Pub/Sub emulator setup, then define the publisher and configuration shape. Done means committed content events produce one appropriately filtered message, projection rebuilds republish nothing, and sensitive fields are absent.

Written by the indexing model from the issue text.