SOUR-108: server-side business object visibility authorization

[Souredfish]

What does this PR do?

Existing Access rules determine whether a member may run an agent; they do not define visibility of business objects. This PR adds a dedicated server-side visibility authorization model for tasks, projects, squads, and their associated data.

The path from the product rule to the implementation is: derive each caller's visible subjects from the confirmed agent/squad mapping, apply the same authorization to object queries and writes, then carry that boundary through search, tables, associated resources, notifications, and realtime delivery. Owner/admin rescue access is audited, and lifecycle events preserve the authorized recipients computed before deletion or archive.

Related Issue

Multica issue: SOUR-108 (workspace issue ID 01a11c16-5cd2-7423-a999-a63d04c5cd12). No matching GitHub issue exists, so there is no GitHub Closes #... reference.

Type of Change

• Bug fix (non-breaking fixes to authorization/query behavior)
• New feature (server-side business-object visibility authorization)
• Refactor / code improvement (no behavior change)
• Documentation update
• Tests (adding or improving test coverage)
• CI / infrastructure

Changes Made

• Added centralized subject derivation, object checks, query filtering, and rescue auditing in server/internal/handler/object_visibility.go and handler entry points for tasks, projects, squads, and child resources.
• Applied visibility filtering to search, issue table rows/groups/facets, inbox/archive summaries, notification listeners, and WebSocket event recipients; preserved pre-delete project/squad audiences and fail-closed standalone daemon task events.
• Added audit and visibility SQL functions in migrations 565_object_visibility_audit and 566_business_visibility_functions; updated inbox/agent/workspace-delete SQL and generated sqlc files.
• Added or updated handler, listener, and authorization regression tests, including rescue audit writes outside read-only table snapshots.

How to Test

1. Run the backend CI job with PostgreSQL (pgvector/pgvector:pg17) and Redis (redis:7-alpine) services. It runs go build -race ./..., go vet -race -tags agentintegration ./..., go run ./cmd/migrate up, the Go test wrapper, and bash scripts/test-go.sh --race --only regular.
2. Run the sqlc check: make sqlc, then verify git diff --exit-code -- server/pkg/db/generated and that no untracked generated files remain.
3. Confirm the authorization regressions in the backend handler/listener tests, including rescue audit persistence, notification recipient filtering, task message access, and pre-delete event audiences.

Local Go tests were unavailable because the authoring shell has no Go toolchain. CI run 37864431482 on head 0050396f7dfb9bcd2f08230b5dbb28ecaeab12f9: backend-tests (including migration up), sqlc-check, backend-agent-tests, Windows execenv, and frontend passed. The vulnerability scan failed on GO-2026-6617 in the Go 1.26.8 standard library (net/http); govulncheck reports Go 1.26.9 as the fixed version. This also causes the aggregate backend gate to fail; it is not introduced by this PR's changes.

Checklist

• I have included a thinking path that traces from project context to this change
• I have run tests locally and they pass — local Go toolchain unavailable; see CI validation above
• I have added or updated tests where applicable
• If this change affects the UI, I have included before/after screenshots — N/A, server-only change
• I have updated relevant documentation to reflect my changes — N/A, no client-facing contract or documentation change
• If I added a new runtime / coding tool / UI tab, I synced the change to landing copy and relevant docs — N/A
• If this PR touches Chinese product copy, I checked it against the Chinese conventions — N/A, no product copy changed
• I have considered and documented any risks above
• I will address all reviewer comments before requesting merge

AI Disclosure

AI tool used: Multica Agent (Codex)

Prompt / approach: Implement the approved server-side visibility rules without changing their semantics; inspect each read/write/event path, add centralized authorization and regression coverage, then use repository CI to validate backend tests, migrations, and generated SQL. Review findings were used to fix implementation/test issues and complete this PR description.

Screenshots

N/A — server-only change.

[vercel]

Someone is attempting to deploy a commit to the IndexLabs Team on Vercel.

A member of the Team first needs to authorize it.