Accounting and Email.Resend move to a personal repo: BaryoDev keeps core, primitives and barakoBrew

BaryoDev holds the core, the primitive modules and barakoBrew. Two modules move to a personal
repository and are published from there.

Related: #136 decides what we build and what the community builds, and #249 is the primitive-modules
epic. This issue is the other half of the same line, applied to what already ships.

## Decided

**Moving out:** `BarakoCMS.Accounting` and `BarakoCMS.Email.Resend`.

**Staying:** everything else, all twelve. `Analytics.Umami`, `Pwa` and `Diagnostics` stay despite being
narrow, `Email.Smtp` and `Files.S3` stay because a protocol with many implementations is not a product,
and `AI` stays because it is not a vendor integration at all: its description is semantic search over a
self-hosted Ollama model that "needs no third-party API key".

The line, for the next module anyone adds: it stays if it is a capability any instance might want, and
it moves if it is the adapter for one named product or a business domain the CMS does not need.
Accounting is the second kind. Double-entry accounting is a domain, not a cross-cutting primitive.

## The blocker is the test suite, not NuGet

This is the part to plan. Both modules are load-bearing in `BarakoCMS.Tests`, which holds every backend
test, and neither can leave without deleting coverage first.

**Accounting is the core's reference module.**

- `CapabilityVocabularyTests.cs:52` asserts the capability vocabulary reports a module as the source of
its capability, and it uses `AccountingCapabilities.ViewLedger` and `AccountingModule` to do it. That
is a test of core behaviour that happens to be written against an optional domain module.
- `IntegrationTestFixture.cs:175` registers Accounting in the shared host on purpose, with the reason
stated in the comment: its content lifecycle hooks put the balance invariant and the chart-of-accounts
rules behind the generic `/api/contents` endpoint, "the whole point of modelling accounting as
content". Every integration test runs against that host.

**Resend is in seven test files:** `EmailSettingsTests.cs`, `IntegrationTestFixture.cs`,
`OpenApiTagTests.cs`, `RecordingEmailService.cs`, `ResendWebhookTests.cs`, `SeedDemoContentTests.cs`,
`SuiteCompositionTests.cs`. `RecordingEmailService` is a test double built on its types, and the Suite
composition and OpenAPI tag tests assert over a Suite that includes it.

So the prerequisite is a purpose-built fixture module in `BarakoCMS.Testing` (which stays, it is the
module author's harness) providing what the core's tests actually need: a module with a capability to
name, content lifecycle hooks carrying a domain invariant, and an email provider double. A core
mechanism proven through an optional domain module is a coupling worth removing whether or not anything
moves.

## One thing that is clean

`IEmailService`, `IEmailSettingsProvider` and `IEmailVerificationService` all live in
`barakoCMS/Core/Interfaces/`. The contract stays in the core, so moving Resend does not take the
interface with it, and `Email.Smtp` mentions Resend only in two doc comments, not in code.

## The rest of the cost

- **The Suite.** `BarakoCMS.Suite` reaches both by `ProjectReference`. It either stops bundling them,
which changes what `ghcr.io/baryodev/barako-cms` contains and is breaking for anyone sending mail
through Resend today, or it takes a `PackageReference` on a package built in a personal repository,
which makes the org's meta-package depend on a build nobody in the org gates. Pick one deliberately.
- **The package ID.** NuGet ownership is per ID and not tied to a repository, so both can keep their IDs
and consumers change nothing. `RepositoryUrl` and Source Link provenance change, and each README
should say where it is built.
- **The shared props.** `Directory.Build.props` and `Directory.Packages.props` give every module its
target framework, nullable setting, licence metadata and pinned versions. Each moved module needs its
own copy, and those copies drift first.
- **The image.** The quickstart compose says the API image "carries every module". If that stops being
true, that line and `docs/module-inventory.md` both change.

## Order

1. Build the fixture module in `BarakoCMS.Testing` and move `CapabilityVocabularyTests` and the shared
fixture onto it. Nothing moves before this; it is most of the work.
2. `BarakoCMS.Accounting` first. No operator has a live path through it the way a mail provider has, so
a mistake costs less.
3. Decide the Suite question from what that move actually cost, not from this list.
4. `BarakoCMS.Email.Resend`, with the Suite answer already settled, because an operator sending mail
through it is the one person a wrong answer reaches.

Milestone 5.0.0, because the Suite question is breaking whichever way it goes.

Start in BarakoCMS.Testing and inspect CapabilityVocabularyTests.cs, IntegrationTestFixture.cs, and the seven Resend-related test files named in the issue. Trace the Suite project references, Directory.Build.props, and Directory.Packages.props before deciding how the fixture and module boundaries should work. Done means the relevant tests run without Accounting or Resend coupled into core coverage, and the Suite, image documentation, and package metadata reflect the chosen arrangement.

Written by the indexing model from the issue text.