[v2][backend] Introduce a repository layer to remove direct Supabase calls from services

[Calebux]

Context

Supabase queries are written inline throughout backend/src/services and backend/src/routes. Missing .eq('user_id', ...) scoping has already produced real bugs (see the closed tag-helper and subscription-scoping issues), and because each call site rebuilds the query, a fix in one place does not protect the next one written.

Scope

• Create a repository per aggregate (subscriptions, payments, reminders, tags, audit, sessions) exposing intent-named methods.
• Make user scoping a required constructor argument of the repository so an unscoped query is not expressible.
• Move every direct supabase.from(...) call in services and routes behind a repository.
• Add a lint rule banning supabase.from outside **/repositories/**.

Acceptance criteria

• Every aggregate has a repository with user scoping enforced at construction.
• grep -r 'supabase.from' backend/src --include='*.ts' matches only files under a repositories directory.
• A lint rule enforces that boundary in CI.
• Repository methods have unit tests, including tests that a cross-user read returns nothing.

Files / areas

backend/src/services, backend/src/routes, backend/src/repositories, eslint.config.mjs

---

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

[Shadow-ui-maker]

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

I'd be glad to handle this issue. I'll keep the implementation concise, maintainable, and well-documented.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Shadow-ui-maker to this issue.

[Jayking40]

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

I'd like to work on this issue. I have strong experience with typescript, express, next.js, soroban and can deliver a clean, well-tested implementation.

My approach:

1. Analyze the existing codebase and understand the current architecture
2. Implement the solution following project conventions and patterns
3. Write comprehensive tests and ensure all existing tests pass
4. Submit a clean PR with clear documentation

ETA: within 24 hours

I'm available to start immediately and can provide regular progress updates.

GitHub: @Jayking40

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Jayking40 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.