Cross-tenant IDOR: scope by-UUID queries to the active tenant

Code-complete (pending commit). Added and tenant_id = ?::uuid (from TenantContext) to every by-UUID path in PostgresTaskSystem: taskById, getTaskDetail, listComments (via join to issue), listActivity (via join), updateTask (current-read + the update statement), and deleteTask. Cross-tenant by-id access now returns not-found / no-op, matching the reorderTask/moveTask pattern.

Regression test added: PostgresTaskSystemTest.byIdPathsAreTenantScoped — asserts a second tenant holding a known issue UUID cannot read detail/comments/activity, cannot update or delete it, and the owning tenant's data is untouched. Full suite green (93 tests).

Completed on develop (32a1fa2).

On review, the core IDOR was already closed: taskById, getTaskDetail, listComments, listActivity, deleteTask are all tenant_id-scoped, and updateTask does a tenant-scoped current-read and early-returns (if (cur == null) return false;) so its label/event writes are unreachable for an out-of-tenant issue.

Two checklist items remained, now done:

1. Label write — the insert into issue_label accepted a raw label_id from the caller with no tenant check (could attach another tenant's label to your own issue). Scoped the insert to label rows owned by the active tenant (foreign/bogus ids are silently skipped).
2. Regression test (the acceptance criterion) — added two through-the-DAL tests: a tenant-A caller cannot read/mutate/delete a tenant-B issue / comments / activity by UUID (and B's data stays intact), and updateTask won't attach a foreign label. All 37 PostgresTaskSystemTest tests pass.

Acceptance met.