Content Drive Action Center: add bulk Lock and Unlock quick actions

[rjvelazco]

Description

Add Lock and Unlock to the Action Center's Quick Actions. Both appear in the design but were left out of the first release because neither has a bulk REST endpoint — see the linked task.

Current state

• Single item already works in Content Drive: the row context menu locks/unlocks via PUT /api/v1/content/_lock|_unlock/{inodeOrIdentifier}, with GET /api/v1/content/_canlock/{inodeOrIdentifier} deciding what to offer.
• LOCK / UNLOCK are not SystemAction values, so the multi-contentlet endpoint POST /api/v1/workflow/actions/default/fire/{systemAction} — which powers every other quick action — cannot fire them.
• Legacy has bulk unlock only, and not over REST: cmd=full_unlock_list → EditContentletAction._batchUnlock, which loops the inodes on a background thread. There is no bulk lock anywhere, including legacy.

Two routes — decide before building

Route	Notes
Client-side loop	N calls to the existing single-item endpoints with a concurrency limit, aggregated into the same result shape the other quick actions report. This is what legacy does; it just moves the loop across the network.
New REST endpoints	_bulklock / _bulkunlock taking {inodes: []} and returning BulkActionsResultView. The _batchUnlock logic already exists to port, and permission checks stay server-side where they belong.

Semantics to settle

Locking is per user, which makes bulk unlock different from the other quick actions:

• Unlocking a contentlet locked by another user requires permission. _canlock reports this per item, so a bulk operation needs an explicit rule: skip those items and report them, or refuse the whole batch.
• Eligibility counts come from row state — !locked for Lock, locked for Unlock — but that says nothing about who holds the lock. A count of 3 "unlockable" items may include one the user is not allowed to unlock.

Acceptance Criteria

• Decide client-side loop vs new _bulklock / _bulkunlock endpoints, and record the decision on this issue
• Lock appears in Quick Actions with the number of selected contentlets that are not currently locked
• Unlock appears with the number that are currently locked
• Neither action is listed when it applies to zero selected contentlets, consistent with the other quick actions
• Locks held by other users are handled by a documented rule and reported back to the user rather than failing silently
• Results are reported in the same shape as the other quick actions (succeeded / skipped / failed)
• The grid refreshes and the selection clears after a successful run
• Folders in the selection are excluded, matching the rest of the dialog
• If new endpoints are added: permission is enforced server-side, not just in the UI, and integration tests cover the allowed and denied paths
• Unit tests cover the eligibility counts and the execute path

Priority

Medium

Additional Context

Endpoints in play today:

Purpose	Endpoint	Scope
Lock one item	PUT /api/v1/content/_lock/{inodeOrIdentifier}	single
Unlock one item	PUT /api/v1/content/_unlock/{inodeOrIdentifier}	single
Can the user lock/unlock it	GET /api/v1/content/_canlock/{inodeOrIdentifier}	single
Legacy bulk unlock	cmd=full_unlock_list (Struts, not REST)	batch, loops server-side

Add to Bundle is the other quick action excluded from the first release, for a similar reason — it is only reachable through the legacy RemotePublishAjaxAction servlet rather than a REST endpoint. It is not covered by this issue and is currently untracked.