fix: enforce workspace filter on agent listing — multi-tenant projects (#4223)

[neuralmint]

Fix: Enforce workspace filter on agent listing

Closes #4223

Problem

The agent listing endpoints and agent CRUD operations trusted object identifiers without tying them to the caller's workspace. In a multi-tenant deployment, this allowed tenants to see or mutate orchestration data outside intended API boundaries, or receive misleading success responses.

Solution

Every agent lookup, listing, and mutation is now scoped to the authenticated caller's workspace:

• Workspace-aware Registry: list(), get(), count(), get_enabled(), and register() accept an optional workspace parameter. Cross-workspace lookups return None (no existence leak).
• Session-scoped routes: All /api/v2/agents/* routes extract the workspace from the authenticated session via request.state.session.workspace.
• Guard in the service layer: The workspace guard is built into the shared AgentRegistry methods, not just route-level checks.
• 404 for cross-workspace access: Attempts to read/mutate agents outside the caller's workspace return 404 (not 403), preventing workspace enumeration.
• Disabled/enabled operations restored: Added disable()/enable() methods and AgentStatus.DISABLED enum value to the registry.
• AuthMiddleware restored: Session validation, role checks, and request.state.session injection.

Acceptance Criteria

• Regression tests cover authorized, unauthorized, cross-workspace, and malformed requests
• 27 route-level tests covering workspace isolation
• The API returns 4xx without performing protected lookups for unauthorized requests
• All 48 existing tests continue to pass

Test output

48 passed in 1.52s