feat(fuse,core,gui,cli): one-request move+rename drain, show who shared an item

- A queued rename that also changes folder now lands as one `move-multiple`
  request carrying the target name instead of rename-then-move, so there is
  no half-applied state and no second call for stale name requirements to
  hit (B46 follow-up). A destination name collision moves under a conflict
  name in one step; same-folder renames still use the rename endpoint.
- Shared with me shows the inviter and invite date (GUI subtitle, `pdfs
  shared-with-me`), with a warning when the invitation signature does not
  verify against the claimed inviter's keys. `DirEntry` gains `shared_by`,
  `shared_at` and `shared_by_unverified`, all serde-defaulted.
- Bump `proton-sdk` / `proton-drive-rs` to 0.6.3 (anonymous-node moves,
  `TrashTime` trashed detection).

docs/BUGS.md

@@ -2650,6 +2650,16 @@ collisions without losing the source. Simple rename-only and move-only calls
 remain synchronous. The managed live suite subsequently passed the replacement
 and combined move/rename cases.
 
+**Follow-up (2026-09-15, unverified):** With SDK 0.6.3 the drain sends the
+move and the rename as one `move-multiple` request carrying the target name,
+instead of renaming in the source folder and then moving. That removes the
+second call the stale requirements could hit, and the SDK retries a remaining
+`InvalidRequirements` once with the server's current name hash. A destination
+name collision now moves under a conflict name in one step. Same-folder renames
+are unchanged. The synchronous FUSE `rename` path (`serve_rename`) still renames
+then moves with its bounded retry and has not been converted. Needs a managed
+live run of the combined move/rename cases.
+
 ---
 
 ## B47 — FUSE Accepts Path Components Longer Than NAME_MAX