Add durable native execution fences for task transfer

[Brian Krabach (bkrabach)]

Task transfer needs a native execution fence that survives process restarts and is respected by every supported session consumer. Add a private durable marker checked under the existing writer lock before ownership is replaced. A restricted transfer handle can cancel a staged marker or permanently commit a source; committed sources cannot regain execution. confirm_transfer_commit safely re-establishes persistence after an uncertain acknowledgement without granting an execution or clearing capability.

Marker writes persist newly created directory ancestors, propagate real open/sync failures, and re-establish file/ancestor durability on exact retries. Host applications remain responsible for authenticated transfer receipts and destination verification. All participating CLI/TUI/host runtimes must use this API; old or uncooperative consumers cannot be fenced. The contract documents POSIX/local-filesystem limits and unsupported directory-sync behavior. No transport or application migration is included.

Validation at 907c442b17a83707102c01e80cb5d1a115fdff88:

• 139 focused session/fence/shared-state/handoff/history/export tests passed.
• Independent review and separate fault injection verified directory EIO rejection, repeated failed acknowledgements, restart confirmation, wrong-ID rejection and continued ordinary execution fencing; 46 focused review tests passed.
• Full Foundation suite: 2,357 passed, 50 skipped, one failure reproduced on untouched upstream f025dbf in the same environment. tests/test_grpc_adapter_main.py::TestVerifyModuleType::test_non_isinstance_object_with_mount_passes fails in its own isinstance setup because the installed Core Tool protocol is not runtime-checkable.

This is a bounded dependency for Unified task portability. It has not been accepted on live Mac/Spark hosts and should not be merged as a claim of cross-host application acceptance.