Make Boundary configuration enforce real architectural layers in server/

Splitting this out from #10366 (thread).

Context

server/lib/tuist.ex maintains a long manual list of modules inside a single Boundary block. Every new module gets appended there to silence the “module is not part of any boundary” warning — but the boundary has no deps or exports declarations, so it doesn’t actually enforce anything. We pay the maintenance cost (another line on every new module) without getting the architectural guardrails Boundary is designed to provide.

Proposed scope

• Break the monolithic :tuist boundary into meaningful ones (e.g. Tuist.Accounts, Tuist.Bundles, Tuist.Runs, Tuist.Metrics, one per domain context).
• Declare the public surface of each via exports:, and the allowed callers via deps:.
• Add a CI check that runs mix compile --warnings-as-errors so boundary violations become build failures, not hints.
• Retire the catch-all module list in tuist.ex once every module is claimed by a real boundary.

Non-goals

• No functional code changes — pure compile-time architecture enforcement.
• Not tying the layering to the directory structure unless it turns out to match cleanly.

Why it’s worth doing

The payoff is architectural feedback at compile time instead of at code-review time: every time someone pulls Tuist.Projects.something from Tuist.Metrics, we’d know immediately whether that call crosses a layer it shouldn’t. At current scale the server has ~580 modules and growing; the manual-list approach is already brittle.

Owners

Unassigned — flagging for whoever picks up the next server architecture block.