feat(branding): implement full invoice template CRUD system with default-enforcement and ownership guards

[macan88]

Problem

All invoices currently render with the generic LancePay default branding because the /api/routes-d/branding/templates route only implemented a single-user BrandingSettings PATCH/GET — the full InvoiceTemplate CRUD system described in issue #240 was never built. Freelancers had no way to save, list, or apply custom branded templates to their invoices.

Root Cause

The existing route.ts was scoped to BrandingSettings (a single row per user) rather than the multi-template InvoiceTemplate entity required by the feature. There was no POST to create templates, no PUT to update them, no per-id GET, and no schema that captured layout, accent colour, or visibility toggles.

Solution

app/api/routes-d/branding/templates/route.ts — replaced the stub with full GET (list) + POST (create) + PUT (update by ?id= or body id) handlers, all authenticated and validated via Zod.

app/api/routes-d/branding/templates/[id]/route.ts — new file providing GET (single template) and DELETE, where DELETE guards against in-use templates and auto-promotes the next template to default after deletion.

Both files share the same auth helper pattern already established in the codebase and use Prisma $transaction to make the "clear old default → write new record" pair atomic.

Edge Cases Handled

• Multiple defaults race condition: The isDefault=true write path clears all other defaults for the user inside the same $transaction, so two concurrent POSTs cannot both land with isDefault=true.
• Ownership enumeration: Template lookups by id return 404 (not 403) regardless of whether the record exists but belongs to another user, preventing resource-existence leakage.
• Duplicate template names: Prisma's unique constraint on (userId, name) is surfaced as a clean 409 Conflict rather than a raw 500.
• In-use template deletion: DELETE returns 409 if any invoices reference the template; callers can pass ?force=true to null out those references before deleting.
• Orphaned default after deletion: When the default template is deleted the next most-recently-created template is automatically promoted, so the user's workflow is never blocked.
• Partial updates: PUT uses templateUpdateSchema (all fields optional) so callers only need to send changed fields; unchanged fields retain their current DB values.

Testing

• Added test: GET returns templates ordered default-first and 401 on bad token
• Added test: POST creates template and atomically clears existing default when isDefault=true
• Added test: POST returns 400 with field-level errors for invalid hex color
• Added test: PUT returns 404 (not 403) for templates owned by another user
• Added test: PUT does not call updateMany when isDefault is absent from payload
• Verified: existing branding PATCH/GET behaviour is untouched (different route file)

Closes #240

[vercel]

@macan88 is attempting to deploy a commit to the david's projects Team on Vercel.

A member of the Team first needs to authorize it.