[v2][backend] Adopt a layered module architecture (route -> controller -> service -> repository)

[Calebux]

Context

backend/src has 40+ route files and 80+ service files with no enforced layering. Routes reach directly into Supabase, services import other services freely, and business rules live in whichever file happened to need them first. This is the structural reason the same bug class (missing user scoping, missing audit event, swallowed persistence error) keeps recurring across unrelated features.

Scope

• Define the four layers and what each may import; write it into backend/ARCHITECTURE.md.
• Reorganise backend/src by domain module (subscriptions, payments, reminders, privacy, admin, integrations), each containing its own routes/controller/service/repository/schema files.
• Enforce the layering with an import-boundary lint rule that fails CI on violations.
• Migrate module by module behind the existing route paths so no API contract changes.

Acceptance criteria

• backend/ARCHITECTURE.md documents the layers and the allowed import directions.
• An eslint boundary rule fails CI when a route imports a repository or a service imports a route.
• At least the subscriptions, payments and reminders domains are fully migrated.
• No public API path or response shape changes as part of the migration, verified by the existing route tests.

Files / areas

backend/src, backend/ARCHITECTURE.md, eslint.config.mjs

---

Part of the SYNCRO v2 rewrite. Epic: D — Backend architecture.

[Elsa-tech2026]

@Elsa-tech2026 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hello Maintainers,
I’m a full-stack and smart contract developer with experience building responsive frontend interfaces, scalable backend systems, and secure blockchain applications.
I’m eager to learn, improve, and collaborate with the community while contributing meaningful value. I would appreciate the opportunity to work on this task.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Elsa-tech2026 to this issue.

[believetimothy]

@believetimothy has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hello Maintainer, I can fix this issue.
Please assign me.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @believetimothy to this issue.

[drips-wave]

Congratulations, @llinsss! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @llinsss: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[Calebux]

Reopening this issue for tracking.

PR #1324 has been merged and the contribution is credited — that part is settled and nothing here affects it.

However, the code for this specific issue is not yet in main. The branch rewrites data access across 107 backend files, and 28 of those have changed in main since the branch was opened. Landing only the non-conflicting portion would have left the backend half-migrated, with some modules on the repository layer and others still calling the database directly, so the merge was resolved to main's tree.

@llinsss — the work itself is sound; it needs a rebase onto current main to go in safely. Apologies that this PR was closed rather than reviewed back in August; that was our mistake, not yours.