feat(sharing): let a listed key be edited through PATCH /api/sharings/:id

[argszero]

Summary

A listed key could only be paused, resumed or soft-deleted. PATCH /api/sharings/:id took exactly one field (status), so a wrong quota, plan, model, note or time window could only be fixed by deleting the row and listing it again — losing the row's id, its listing time and its ledger ownership.

This first PR is the backend half: PATCH now accepts the same field set as POST /api/sharings as a partial update. The in-page edit form follows in a second PR.

Related Issue

None — this is the backend half of the host's rant 2026-09-30T13:12:07 (translated from the Chinese original: "A listed shared key should be editable in-page, and every setting from listing time must be changeable"), which asks for the endpoint capability separately from the UI work.

Changes

• src/routes/sharing.rs — PatchSharingReq widened to status + provider / plan / model / key / quota / available / note, all optional: an omitted field is left untouched, a given field is replaced wholesale. status keeps its three values and semantics, soft delete off included. The update keeps WHERE id = ? AND owner_id = ?, and the response still comes from ROW_SELECT, so a row's id, created_at and ledger key_id do not move.
• src/routes/sharing.rs — the two listing guards (the (provider, model) pair must be priceable, the plan must be routable) were inlined in create; they are now one validate_listing helper called by create with the request's values and by patch with the merged values. This endpoint has already grown a second, hand-written copy of one rule once (C2052), so the tests assert more than "both return 400": they assert the two paths answer with the byte-identical error body, and that a rejected request writes nothing.
• src/routes/sharing.rs — the upstream key is three-state. The client only ever holds the server-made mask (mask_upstream_key), so key omitted / empty / whitespace keeps the stored ciphertext and only a real new value re-encrypts. Writing the mask back would invalidate the original key permanently (every later call would 401) with nothing in the UI to say so.
• src/routes/sharing.rs — available distinguishes "omitted" from null via a small serde shim (double_option): omitted = do not touch the window; explicit null = any day, all day, clearing available_days / _start / _end together. A plain Option<Avail> collapses the two and would silently keep a stale window — or, with a per-subfield unwrap_or(cur), leave a half-replaced one. days is serialised exactly as create does it.
• docs/architecture.md — the API list said PATCH was "pause / offline"; it now names the edit capability, so this line does not drift the moment this merges.
• No config / data-structure change (no new column, no migration).

Tests

• cargo test — 451 passed, 0 failed (baseline f63dd66: 446) — 5 new cases.
• cargo fmt --check — clean.
• cargo clippy --all-targets -- -D warnings — clean. RUSTFLAGS="-D warnings" cargo build (the non-test build, the only witness for a field read solely from tests) — clean.
• New tests: full in-place edit of every listing setting (same row, same created_at, days serialised as create does); the stored key survives omitted / empty / whitespace and is replaced on a new value (decrypted encrypted_key must equal the original plaintext and never the mask); partial semantics including available: null clearing all three columns; create/patch validation parity by byte-identical error body plus "no write on 400"; another user's row is 404 while your own row still edits (positive control).
• A/B (each mutation run, then the tree restored byte-identically): always re-encrypt the key → patch_keeps_the_stored_key_when_no_new_key_is_given fails ("" vs "sk-original9999"); drop the serde shim → patch_only_touches_the_fields_it_is_given fails ("[3]" vs "", i.e. the stale window survived); skip the shared validation in patch → patch_reuses_the_create_validation fails (200 where 400 was required). Each mutation turned exactly its own test red.

Checklist

• Branch name follows convention (feat/…)
• Conventional Commits format, no (#N) in the title
• Single responsibility, minimal change

[argszero]

Self-review (this repo allows self-merge; GitHub will not accept an approval from the author, so the review is recorded here).

Read through the diff on the pushed tree and re-ran the suite locally at ca28626:

• cargo test — 451 passed, 0 failed.
• cargo fmt --check, cargo clippy --all-targets -- -D warnings, RUSTFLAGS="-D warnings" cargo build — all clean.
• CI on this PR — test / fmt / clippy and msrv both green.

Three things I checked by hand rather than trusting the tests:

1. status is still optional-validated the same way. {"status":"paused"} / {"status":"on"} / {"status":"off"} behave exactly as before; {"status":"deleted"} is still 400 and another user's id is still 404. Making the field optional does not change any existing client's path.
2. The mask cannot be written back. The only way key reaches encrypt() is req.key being present and non-blank after trimming; the test decrypts the stored ciphertext and asserts it equals the original plaintext and never the mask.
3. available cannot end up half-replaced. All three columns are written from one match arm each, so there is no path that updates available_days while leaving the old start/end (or the reverse).

Scope note: this is the backend half of the host rant; the in-page edit form is a separate PR, so the capability has no UI consumer yet by design.