Public writes: one submission policy on a content type and one signed-link service

Each way an anonymous visitor writes builds its own guard. Registration has a fixed `registration` rate limit (`barakoCMS/Features/Auth/Register/Endpoint.cs:65`). PWA and diagnostics reports use `telemetry` (`BarakoCMS.Pwa/Features/ReportEndpoint.cs:42`). The Forms module in PR #821 brings its own Turnstile check and honeypot (`BarakoCMS.Forms/TurnstileVerifier.cs` in that PR), and share link redeem in PR #860 is another path. Planned work adds more: newsletter sign-up (#846), email codes (#811), booking (#847), a per-form limit (#813). Signed tokens are split the same way: preview tokens (`barakoCMS/Infrastructure/Preview/PreviewToken.cs:16`), share keys, action tokens in #840, confirm and unsubscribe links in #846.

### Why it is too specific

Each feature answers "may an anonymous visitor write this, how often, and is it a person" on its own terms. A school's enrolment form, a clinic's appointment request and a bakery's order form need the same three answers, and today each would be another copy with its own gaps. A form posted through barakoPress arrives from the renderer's address, so a per-IP limit puts every visitor in one bucket.

### The general concept

A public submission policy on a content type: whether anonymous create is allowed, which named rate limit applies (#888), how it partitions (the client address forwarded by a trusted renderer, not the renderer's own), and which bot check runs (none, honeypot, Turnstile). Registration, forms, newsletter and booking read it. Beside it, one signed-link service: purpose, subject, expiry, single use and revocation, signed per purpose. Preview, share, action and confirm links become purposes of it.

### Where it lives

Core: the policy on the content type and a link service in `Core/Interfaces`. Forms and later modules consume both.

### Compatibility

Forms and share links are not released, so they can adopt the policy before they ship, which is why this is cheap now. Registration and preview are released: their current limits and token format stay as the defaults, and a preview token issued before the change keeps validating until it expires. Additive on the HTTP surface.

### Done when

- Forms (#821) and registration read the same policy, and a test shows a form's own limit refusing a submission while registration is unaffected.
- Two visitors posting through one renderer are limited separately, with a test that fails before the change.
- Preview tokens and share links are issued and checked by the one link service, and a token issued for one purpose is refused for another.

Relates #857, #840, #888.

Found in the architecture sweep of 15 September 2026.

Start with the registration and report endpoints, BarakoCMS.Forms/TurnstileVerifier.cs, PreviewToken.cs, and Core/Interfaces to map the existing limits and token paths. Review PRs #821 and #860 alongside the related issues before defining the shared policy and link-service boundaries. Done means the listed forms, registration, preview, and share-link tests cover independent renderer-client limits, purpose isolation, compatibility, and single-use behavior.

Written by the indexing model from the issue text.