[Feature]: Support multiple active workspaces on one cluster

### User problem

Platform operators need to host multiple research teams or projects on one TauGrid cluster. Today only one `TauWorkspace` can be active. Additional workspaces are marked `Degraded` and do not receive a namespace, LocalQueue, or researcher RoleBinding.

The current choices are to share one workspace without a tenant boundary or operate a separate cluster for each team.

### Desired outcome

Allow multiple workspaces to be active on the same cluster. Each workspace should have its own namespace, queue, workload identity, RBAC, and audit boundary. Users should only be able to submit, inspect, and manage workloads in workspaces they are authorized to access.

Existing single-workspace deployments should continue to work without requiring users to select a workspace explicitly.

### Proposed approach

Reconcile each `TauWorkspace` independently instead of selecting one primary workspace. Require `workspace-rbac` for concurrent workspaces, qualify workspace-owned API and storage paths, and keep connection descriptors as the normal CLI selection mechanism.

Ship this in stages. Start with workspace lifecycle and negative-access tests, then enable concurrent workload submission and workspace-scoped Portal views.

### Alternatives considered

A cluster per workspace provides isolation but increases cost and operational overhead. Sharing one workspace is simpler but does not provide separate access, quotas, ownership, or auditing. Namespace separation without enforced workspace authorization is not sufficient.

### Additional context

This is the first item under **Workspaces and multi-tenancy** in the [TauGrid roadmap](https://github.com/Azure/taugrid/blob/main/ROADMAP.md). The current lifecycle is documented in [Workspaces](https://azure.github.io/taugrid/docs/concepts/workspaces/).

**Status:** Exploring
**Owner:** Unassigned

Start with the Workspaces documentation and the Workspaces and multi-tenancy section of ROADMAP.md to understand the current lifecycle and proposed stages. Trace the existing TauWorkspace lifecycle and workspace-rbac entry points, then define the scope for lifecycle and negative-access tests first. Done means concurrent workspaces have isolated resources and enforced authorization while existing single-workspace deployments remain usable.

Written by the indexing model from the issue text.