fix(sync): regenerate .mokuro on cloud volume rename (stop silent revert)

[Gnathonic]

The bug

Renaming a cloud-backed volume moved its .mokuro sidecar but never updated the title/series fields inside it. On re-download to another device, processing.ts trusts the .mokuro's internal metadata over the filename — so for OCR volumes the rename silently reverted and series grouping broke. It affects every provider, so the fix lives in the shared unified-cloud-manager.

The fix — renameVolume(old…, new…, volumeUuid)

• Regenerate, don't move, the .mokuro: generateVolumeSidecarsFromDb(uuid, {seriesTitle, volumeTitle}) gains overrides so the fresh sidecar is built with the new names while the DB still holds the old ones. (The remote rename gates the local commit — a throw skips it — so we never mutate local state first.)
• Flow: collision gate → upload fresh .mokuro at the new path → move .cbz + cover (content is name-agnostic) → delete the stale .mokuro last → best-effort prune the emptied old series dir (WebDAV removeDirectoryIfEmpty, server-checked emptiness).
• Retry converges without error-swallowing: every step is idempotent and the only destructive step is last. A file moved by a prior partial run is simply absent from the fresh source listing, so it never re-enters the move loop.

Safety gates (all fire before any remote write)

• Typed NOT_FOUND, no message sniffing: each provider throws ProviderError('NOT_FOUND') at the boundary where the status is unambiguous. A 404 during a move is a genuine failure (deleted elsewhere / stale id) and aborts before the destructive delete; a 404 during a delete is convergence (absence is the postcondition).
• Collision gate + overwrite prompt: renaming onto a name another backup occupies throws TARGET_EXISTS before the .mokuro upsert could corrupt the occupant's sidecar. The volume editor then offers overwrite-or-cancel; overwrite deletes the occupant explicitly first.
• WebDAV idempotent-retry hardening: "destination occupied + source gone" only counts as our prior move when the occupant matches the source's size (identity proxy, paralleling Drive's id / MEGA's nodeId checks). Any other occupant throws.
• Read-only providers no longer block local-only renames: the READ_ONLY gate fires only when there are actually cloud files to move.
• SIDECAR_REGEN_FAILED: an OCR volume whose sidecar can't be rebuilt (missing volume_ocr) refuses to rename rather than moving the stale sidecar.

Series rename — per-volume, not all-or-nothing

executeRenameSeries now runs one volume at a time; each volume's cloud rename gates that volume's local commit. Failures are collected per volume (accurate message, no false "kept in sync"), the succeeded volumes stay consistent in both places, and retrying the same rename finishes just the stragglers. On full success the view navigates to the new series.

Cloud-only volumes block the rename with a download-first notice: their .mokuro can't be regenerated without local OCR, and renaming around them would split the series across two cloud folders.

TODO(data-update): the proper fix is downloading a volume's .mokuro/metadata without the full archive — blocked on the metadata-persistence data update (metadata surviving volume deletion, see #201).

Title filesystem-safety sanitization (stacked feature)

A pure sanitizeTitleSegment helper substitutes Windows/OneDrive-illegal characters with fullwidth look-alikes (plus control-strip, dot-leader, reserved-name, and trim rules), applied at the title write points: local import, series rename, and volume rename.

Cloud downloads are exempt (preserveTitles): their titles must keep matching the remote path, or legacy backups with : ? * etc. would read as un-backed-up (duplicate uploads) and renames would miss their files — re-enabling the very revert bug this PR fixes. Legacy titles get sanitized on their next rename, when the cloud files move along with the title.

Verification

• 753 unit tests, svelte-check clean. New coverage: read-only + local-only rename proceeds, move-failure aborts before the destructive delete, retry convergence via absent sources, TARGET_EXISTS gate + overwrite path, cloud-only block, per-volume failure collection, partial local-commit filtering, WebDAV size-verified idempotency, typed 404 mapping, preserved cloud-download titles.
• Two review passes (adversarial multi-agent); all confirmed findings folded in.
• Manual test checklist:
  • Rename a cloud-backed volume (WebDAV/MEGA/Drive) → re-download on second device keeps the new name
  • Rename a volume onto an existing backup's name → overwrite/cancel prompt; cancel changes nothing
  • Rename a series with a volume deleted locally but still in cloud → blocked with download-first notice
  • Rename a series over flaky connection → partial failure reports which volumes failed; retry finishes them
  • Rename a never-backed-up volume while connected to a read-only server → succeeds locally
  • Re-download a legacy backup whose name contains : or ? → still shows as backed up, no duplicate upload

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
mokuro-reader	Ready	Preview, Comment	Jul 4, 2026 5:01pm

[Ceynou]

Is the renaming function disabled until this is merged?

[Gnathonic]

Is the renaming function disabled until this is merged? @Ceynou

Nah, the bugs that come from renames as it stands are minor and can be fixed with a quick script.
This is to fix the need for the script and other bugs that come from things as they stand.
This fix if done poorly has the ability to make things worse, hence the slowness in finalizing.
Will probably merge in today.