[FEATURE] Bulk API Architecture

### Certification

- [x] I certify I am an Epic Owner for Kubeflow Notebooks 2.0 and expected to create planning-related issues.

### Motivation

RESTful conventions do not prescribe a common pattern for handling bulk operations. Before implementing
bulk actions across the various resource types in Notebooks 2.0 (Workspaces, Secrets, Volumes, Image
Assets), the community needs to agree on a consistent architectural approach that can be applied uniformly.

Common approaches typically fall into one of two camps:

Option A: Frontend Orchestration
- No dedicated bulk endpoints at the API level
- Frontend issues multiple individual API calls in parallel or sequence
- Simpler backend implementation; complexity shifts to frontend
- Progress and error handling managed client-side

Option B: Dedicated Bulk Endpoints
- Each resource type exposes a bulk operation endpoint
- Request body contains an array of operations (action + resource reference + parameters)
- Backend processes operations and returns aggregated results
- Atomicity, partial failure handling, and progress reporting managed server-side

Each approach has tradeoffs around complexity, error handling, transactionality, and user experience. This
feature establishes a transparent discussion and agreement on the preferred strategy so that bulk
operations can be implemented consistently across all applicable resource types.

### High Level Design / Mock-ups

Key considerations for the architecture discussion:

- Consistency: Whichever pattern is chosen should apply uniformly across Workspaces, Secrets, Volumes, and
Image Assets
- Error Handling: How are partial failures reported? (some operations succeed, others fail)
- Atomicity: Should bulk operations be all-or-nothing, or best-effort?
- Progress Feedback: How does the user know the status of long-running bulk operations?
- Authorization: How are permissions checked—per-item or as a batch?
- Idempotency: How are retries handled safely?

### Acceptance Criteria

- [ ] Community discussion on bulk API architectural approaches is documented
- [ ] Preferred approach (frontend orchestration vs. dedicated bulk endpoints) is agreed upon
- [ ] Error handling and partial failure strategy is defined
- [ ] Authorization model for bulk operations is defined
- [ ] Agreed architecture can be applied consistently across all resource types requiring bulk operations

No source files, tests, or entry points are named. Start by comparing frontend orchestration with dedicated bulk endpoints across Workspaces, Secrets, Volumes, and Image Assets, then document the community discussion, preferred approach, error handling, authorization, and a consistent architecture.

Written by the indexing model from the issue text.