fix(receiver): confine the --delay-updates staging path to the module

[oferchen]

Closes the operator-path-partial-dir-daemon divergence by refusing the escaping operand, which is what upstream does and what the Linux baseline already encodes. Supersedes #7657, whose shape (clear the symlink and proceed) was the operand-ignored outcome the cell rejects.

The defect

On a daemon receiver --partial-dir is peer-supplied. --delay-updates stages every file through <--partial-dir>/<basename> and later renames it onto the destination. Both of those renames walked the ownership walk in its Ancillary spelling, and AbsPathTracker::start returns Disabled for anything that is not PathKind::Confined — so the session confinement root was never consulted on this path at all.

A symlink standing at the partial-dir name therefore sent the staged file — a complete copy of the source — outside the served module, and the delayed sweep then renamed it back over the destination.

Measured with the cell's own fixture (module mod with blink -> <outside>/secret planted inside, -a --delay-updates --partial-dir=/blink src/ <url>mod/):

	exit	mod/f0	outside secret/f0
before	23	replaced	destroyed
after	11	untouched	intact

How it was localised

create_partial_dir and partial_dir_rename were both excluded by instrumentation first — neither is on this path. Probing every operator_* entry point named the two real sinks:

ENTRY operator_rename        path=".../mod/blink/f0"     <- receiver/transfer.rs sweep_rename
ENTRY owner_trusted_parent   path=".../mod/blink"        <- Ancillary, tracker DISABLED

Both halves are load-bearing

Measured in isolation, not assumed:

	exit	dest	victim
neither confined	23	REPLACED	DESTROYED
sweep only	23	untouched	DESTROYED
both	11	untouched	intact

Confining the sweep protects the destination; confining the staging rename protects the victim. Neither alone is sufficient.

Why not rename_config_sandboxed

The staging endpoint deliberately does not reuse it. Its renameat_via_sandbox_or_fallback helper drops to a path-based rename when the anchored open fails — the drop-to-unconfined that upstream names as wrong. syscall.c open_dir_secure() signals policy with errno == 0 precisely so a runtime errno cannot select the unconfined arm.

Upstream

• util1.c:1518-1530 handle_partial_dir(..., PDIR_CREATE) runs the whole retention under operator_path_resolve
• syscall.c:1891 do_rename_at() under that flag
• receiver.c:546 do_rename(partialptr, fname) — the sweep rename

Verification

• macOS upstream 3.5.0 testsuite on this exact base: 237 passed / 3 failed (was 235/5). operator-path-partial-dir-daemon passes.
• The three residual rows are the ones the manifest header already classifies: chmod-setid and partial-protected-regular-retry-policy are unsatisfiable on this host (real rsync 3.5.0 lands on the same result), filter-merge-content-echo is owned separately.
• macOS nonroot expect manifest flips the row fail -> pass in the same commit; the header's count and classification list are reconciled with it.
• cargo fmt --all -- --check and cargo clippy --workspace --all-targets --all-features clean on the pinned 1.88.0 toolchain.
• The relative-operand control is unchanged (exit 11, dest untouched, victim intact) before and after.