[Proposal] Bulk Edition Editing with Backend Support

### Feature Request

This proposal addresses Item 2 of the [Librarian Feature Requests Tracking Epic #11505](https://github.com/internetarchive/openlibrary/issues/11505).

## The Problem
Currently, librarians must edit editions one by one. This is inefficient when updating shared metadata (e.g., Publisher, Language, Publish Date) across multiple editions of the same work. This friction leads to data inconsistency, as users often update one edition and skip the rest.

## Proposed Solution
Implement a "Bulk Edit" mode within the existing editions template. The primary goal is to perform updates via a new atomic backend endpoint, with a robust client‑side UI to manage selection and feedback.

## Context
This feature is a prerequisite for more advanced workflows like "Duplicate Edition" (see discussion in #11516). By implementing this, we unblock power users immediately.

### Breakdown

## UI Implementation (HTML/Templates)
- [ ] Modify `templates/type/work/view.html`:
- Add a "Bulk Edit" toggle button to the editions table header.
- Inject a hidden `` column with checkboxes for every edition row.
- Add a "Select All / Deselect All" master checkbox in the table header to quickly toggle all visible editions.

### UI Mockup (Concept)

[ Mockup: Bulk Edit Mode ]

| [x] | Cover | Title | Publisher | Year |
|-----|-------|-----------------|-----------------|------|
| [x] | [img] | The Hobbit | Allen & Unwin | 1937 |
| [x] | [img] | The Hobbit | HarperCollins | 1999 |
| [ ] | [img] | The Hobbit | Houghton Mifflin| 2002 |

-------------------------------------------------------
[ Sticky Footer Action Bar ]
Action: [ Change Publisher v ] To: [ HarperCollins ] ( Apply to 2 Editions )
-------------------------------------------------------

- [ ] Action Bar: Add a sticky footer container (`div#bulk-action-bar`) containing:
- Target Field Selector (e.g., Publisher, Date).
- Value Input (dynamically changes based on selector).
- "Apply" Button.

## Backend Interaction (Hybrid Strategy)
To avoid "chatty" API usage (N+1 requests) and ensure data integrity, I propose two possible paths:

**Path A (Preferred – Backend)**
- Implement a new `POST /api/editions/bulk` endpoint in Python.
- Input: List of OLIDs and a changeset (e.g., `{'publisher': 'Penguin'}`).
- Logic: The server iterates, validates permissions, applies changes, and returns a summary.
- **Why this is preferred:**
- **Atomicity:** Ensures partial updates don’t leave the database in an inconsistent state.
- **Performance:** Reduces network overhead from N HTTP requests to 1.
- **Scalability:** Handles large selections (e.g., 50+ editions) without client‑side timeouts.

**Path B (Fallback – Client‑Side)**
- If a new endpoint is out of scope, implement a client‑side queue in JS.
- **Rate Limiting:** Enforce a strict delay (e.g., 500ms) between requests.
- **Sequential Processing:** Update items one by one to prevent server flooding.

## Client‑Side Logic (`static/js/editions-bulk.js`)
- [ ] **State Management:** Track selected IDs and the "Bulk Mode" active state.
- [ ] **Feedback Loop:**
- Display a progress counter (e.g., "Updating 3 of 10...") in the Action Bar.
- Partial Failures: If a request fails, flag the specific row in red and continue to the next one (do not crash the whole batch).
- [ ] **Safety:** Trigger a confirmation modal before execution: "Are you sure you want to update [Field] to '[Value]' for X editions?"

## Testing & Validation
- [ ] **Unit Tests:** Add Python tests for the new bulk endpoint (if Path A is chosen), covering permission checks and invalid inputs.
- [ ] **Integration Tests:** Verify that the "Select All" logic works correctly across different pagination states.
- [ ] **Manual QA:** Verify that bulk edits correctly trigger search index updates (Solr).

## Permissions & Safety
- **Role Restriction:** This feature will be restricted to accounts with the `Librarian` role or higher. Standard users will not see the "Bulk Edit" toggle.
- **Audit Trail:** Every bulk edit action will generate a standard version history entry for each affected edition, preserving the `last_modified_by` user attribution.

## Rollout Strategy
- **Feature Flag:** The UI will be wrapped in a feature flag (e.g., `enabled_bulk_edit_ui`).
- **Phased Rollout:** Initially enabled only for staff/admins for testing, then gradually rolled out to the wider Librarian community.

## Acceptance Criteria
- [ ] Users can toggle bulk mode and use "Select All" to manage large lists.
- [ ] The system handles partial failures gracefully (e.g., 1 out of 10 fails) without stopping the process.
- [ ] A summary notification (Toast/Alert) appears upon completion.
- [ ] The feature is covered by automated tests.

Start by reading templates/type/work/view.html and static/js/editions-bulk.js, then review the acceptance criteria and the proposed Path A versus Path B. Confirm the backend entry point and feature-flag approach with maintainers before implementation. Done means librarian-only bulk selection, safe updates with feedback, automated coverage, and verified search-index updates.

Written by the indexing model from the issue text.