fix(fuse): extend FUSE_INTERRUPT decoupling to write paths

[mfreed]

The previous two fixes (4c7b4c1, b5cf146) decoupled FSAdapter and OpsNode read paths from the kernel's per-request context to stop FUSE_INTERRUPT (typically from Go SIGURG goroutine preemption under GC pressure) from spuriously cancelling DB queries. The decision to exclude write paths was based on the assumption that partial writes would have real consistency implications -- but that assumption was wrong: every tigerfs write op is either a single auto-committed statement or a single transaction wrapping a few atomic statements (DeleteAndUpdate for POSIX rename-as-replace). There is no partial state to leak when we ignore a transient cancellation; the kernel's FUSE_INTERRUPT is "you may stop early if you want," not "abort, the syscall is dying."

Symptoms previously observed in docker-FUSE stress (~10% rate per 1500-iter run, on top of the cache-bug rate fixed in b5cf146):

• close-time EIO during create_file / edit_file (Flush -> WriteFile)
• rename ENOENT during move_file / rename_file (internal lookup of source path inside renameSynthFile gets cancelled, propagates as ErrNotExist)
• delete ENOENT during delete_file (similar, internal lookup of victim path gets cancelled)

Fix: add ctx = decoupleFromRequestCancel(ctx) to FSAdapter's four write methods (WriteFile, Delete, Mkdir, Rename). Update the decoupleFromRequestCancel doc comment to reflect that it now applies to both read and write paths, with the atomicity reasoning.

Tests: four new unit tests in adapter_ctx_test.go, symmetric to the existing read-path tests. All 9 decoupling tests pass.

Validation: 15/15 clean across 37,500 docker-FUSE stress iterations (--iterations 2500 --validate-every 1 --large-files --many-files).