feat: add folder-grouped tabular review rows

[ecarjat]

Summary

Focused replacement for #54, rebased on the current main branch.

Changes

• Adds an optional folder grouping mode when creating a project tabular review.
• Persists review rows and their source documents, while preserving document-level rows for files outside a subfolder.
• Adds the schema migration, fresh-schema support, and backend-owned table access hardening.

Why

Lets a tabular review process all documents in a project subfolder as one logical row without coupling the change to the separate page-limit or PDF.js cleanup work from #54.

Testing

• npm test --prefix frontend
• npm test --prefix backend
• npm run build --prefix backend

[CLAassistant]

All committers have signed the CLA.

[amal66]

Thanks for splitting this out of #54. The idempotent migration with a legacy backfill, the create-path rollback, and the revoke + RLS on the two new tables — matching, even exceeding, the repo's backend-owned-table pattern — are genuinely good work.

The core problem is that the feature currently ends at the database. Must-fix:

• Folder rows are write-only. Cells are inserted with document_id: null, but /generate, /regenerate-cell, and the table UI all key on document_id, so folder cells stay pending forever and the checkbox ships a broken state.
• Frontend tsc --noEmit fails with three errors from widening TabularCell.document_id to string | null, which breaks next build.
• Rebase: schema.sql conflicts with main's pagination RPC rework — the resolution must keep main's new functions — and the migration is dated before ones already shipped on main, so operators would skip it; rename it to a later date.
• PATCH /:reviewId edits cells by document_id only and never maintains the new rows/sources tables, so folder reviews desync on edit.

Smaller: several helpers ignore Supabase errors (a transient failure yields a silently empty review), and adding the two new tables to the stack test's PUBLIC_TABLES would enforce the hardening claim in CI.

To make this easy to act on I've opened ecarjat#1 against your branch: row-based generation and rendering wired end to end, the tsc errors and migration date fixed, tests added — merge it or cherry-pick. It sits directly on your branch as three focused commits; the rebase onto main (including the schema.sql resolution) is left to you. On the result, both typechecks are clean and both suites pass (backend 268, frontend 41).

[amal66]

Details in my comment below — the schema work is solid, but generation/rendering aren't wired to the new rows yet, the frontend typecheck fails, and the migration needs re-dating. There's a follow-up PR against your branch implementing the fixes.