feat(quarantine): add ak quarantine hold, and document the command group

[brandonrc]

Summary

Two gaps in the quarantine command group, which shipped in v1.2.0 (#102) with status, release, and reject.

No hold subcommand. The backend registers four quarantine routes and the CLI covered three, so placing a manual admin hold was the one quarantine operation with no command and an admin responding to a bad artifact had to hand-roll an HTTP call. Adds ak quarantine hold <artifact-id> [--reason] against POST /api/v1/quarantine/{artifact_id}/quarantine.

--reason is optional, matching QuarantineNowRequest.reason on the backend (the server records a default when the field is absent) and matching the existing reject subcommand. It is deliberately not required.

The vendored SDK's ClientQuarantineExt predates this route and exposes no quarantine-now operation, so the call goes over the raw HTTP path already used for post-SDK endpoints rather than blocking on an SDK regen. That path exposes the status code, so 403, 404, and 409 get actionable messages instead of a bare transport error.

Undocumented. ak quarantine never made it into the README command list or the CHANGELOG, so the only way to discover it was ak --help. Added to both. The CHANGELOG entry for the existing subcommands goes under 1.2.0 rather than Unreleased, because that is the release it actually shipped in. completion.rs needs no change; it derives from the clap tree via Cli::command().

Testing

cargo test quarantine: 26 passed, 0 failed. cargo fmt --check clean, cargo clippy no errors.

New tests follow the module's existing style (clap parse tests plus wiremock-backed handler tests):

parse_hold_with_reason / parse_hold_no_reason / parse_hold_missing_artifact
handler_hold / handler_hold_no_reason / handler_hold_invalid_uuid
handler_hold_forbidden_mentions_admin      (403)
handler_hold_not_found_mentions_artifact   (404)
handler_hold_conflict_is_error             (409)

Not manually tested against a running instance.

Notes for review

ak quarantine list is deliberately not implemented. The backend has no endpoint listing quarantined artifacts; all four routes are keyed by a single artifact_id. It needs a backend counterpart first.

The reject signature is unchanged. RejectRequest.reason is Option<String> on the backend, and making --reason required there would be a breaking change to a released command.

No dependency on the other quarantine work in flight: POST /quarantine/{id}/quarantine already exists on the backend's main. This PR can merge independently.

Closes #156

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud