Activity for a single workspace, drawn from its team's audit trail.

⚠️ A SEPARATE ENDPOINT, NOT A workspace_id PARAMETER ON GET /v2/teams/{team_id}/activity. Three reasons, and the first is the one that matters:

1. THE TEAM ENDPOINT 403s A NON-TEAM-MEMBER (team_routes.py, its team.is_member guard). A workspace OWNER need not be in the team — and is exactly who opens a workspace page. Reusing that route would 403 the owner on their own workspace. This route is guarded by require_workspace_context(WORKSPACE_VIEW), which resolves all four access paths (owner / direct / team / dual) and lets the owner in.
2. The caller has a workspace id and may not know the team id — or there may not be a team at all.
3. The resource being described is the workspace.

⚠️ FILTERED IN MEMORY, NOT IN THE QUERY. Deliberate, with a known ceiling:

• TeamAuditEvent.team_id is required and every repository query filters on it; there is no query path by workspace, so a query-side filter needs a new composite index AND a field that most existing rows lack.
• list_by_team ALREADY streams the whole team's events and paginates in memory (firestore_team_audit_repository.py list_by_team), so filtering here adds no new read pattern — it reuses the one that exists.
• The 90-day TTL bounds how large a team's trail can get.
• It also catches legacy rows that predate workspace_id, which a query on that field could not. The trade is real: we fetch the team's events to keep a subset. If a team ever accumulates thousands of events in 90 days, this should become a list_by_workspace query with an index on (workspace_id, created_at).

Access: anyone who can view the workspace.