Filesystem.LinkCreateNew: create-only link with a typed cross-device refusal, one realization for seed and emitted programs

[gunbai-bot]

C1b-1 of the cross-run materialization sequence (royal-moth-86 ruling, 2026-10-03). Off main, not stacked. It adds the create-only file-to-file publish that C1b-2 needs to place a staged executable in the materialization store root. C1b-2 stacks on this, #13081 and #13082. Consumer: bold-dove-431's compute family (belt-verify binaries).

What it adds

• extdeps.filesystem.filesystem_io Filesystem.LinkCreateNew(source, path). This is one link(2): the name appears with the source's bytes complete or not at all. Create-only: an existing target answers already_exists. A source on another filesystem refuses: a link across filesystems is not a copy, and nothing falls back to one. The source is left in place for its owner.
• New failure kind FilesystemCrossDevice ("cross_device", from the host's ErrorKind::CrossesDevices), admitted on the closed roster. The admission still refuses an unknown name and never folds it into other. Every exhaustive match on FilesystemFailureKind gains the arm: exact-read, create-new, link, and the store's fault mapping.
• Typed classifier filesystem_link_create_new: Linked | LinkTargetOccupied | LinkCrossDevice { source, path } | LinkRefused { kind } | LinkKindUnrecognized.

One realization, no second transport

• gunbc_file_link_create_new (= std::fs::hard_link) is added to extdeps.filesystem.rust_realization's one canonical block. Both projections carry that block: the seed's committed gunbc_file_transport_generated.rs and the emitted program's v1_rt. So the seed and emitted programs run the same bytes, and the existing byte-equality control covers it.
• Interpreter (v1_interpreter dispatch_file): a link_create_new arm calls that generated function, and io_error_kind_name maps CrossesDevices.
• Emitter (v1.compiler.emit / emit_rust): new FileLinkCreateNew verb, rendering v1_rt::gunbc_file_link_create_new(&source, &file_path). The emitted file_io_error_kind maps CrossesDevices. The binding wall gains FileLinkMissingSourceInput: an operation with this verb and no source input refuses rather than inventing a path.
• Stage0 mirrors regenerated on BuildBuddy (--required-regen installed until clean, then main_wet and the docs projection regen). The fixed point is equal (fixed_point_equal=true, referenced_first_generation_equal=true) on the tree merged with current main.

Evidence (dag/test/claim/filesystem_link_create_new_wet_witness_test.dag, BuildBuddy, all PASS; cargo clippy --all-targets -D warnings clean)

• By real execution: a link publishes the source's bytes and keeps the source. An existing target refuses as occupied and keeps its bytes. A missing source refuses with FilesystemNotFound and nothing appears.
• Classifier: cross_device classifies as LinkCrossDevice, and an unknown kind is LinkKindUnrecognized, not a refusal.
• Cross-device, by real execution: a_link_across_filesystems_refuses_as_cross_device_by_real_execution stages the source in /dev/shm and links into a /tmp root. It asserts its own precondition: the two directories' st_dev (new coreutils.Stat.PathDevice, stat -c %d) must differ. Where they don't, the claim is RED, never falsely green. On BuildBuddy, /tmp is ext4 (dev 65024) and /dev/shm is tmpfs (dev 19), and the link refused as FilesystemLinkCrossDevice. 6/6 PASS.
• The four real-execution witnesses are enrolled as held route gaps (DirWithTemplate has no mock) and scheduled on the local-repo wet lane, like the other file-store wet witnesses.

v1 maintenance standing (DESIGN section 3)

Admitted under the purpose test: it serves the v2 self-host program's materialization lane. It is the create-only publish the bounded store needs to hold staged binaries, and the emitter half is required so the store's emitted closure (#13078's control) keeps emitting once the store calls it.

Do not merge from this session; the operator lands it.

🤖 Generated with Claude Code

[gunbai-bot]

Addressed review 74665 in d527bde.

• No production consumer: correct within this PR. The consumer is extdeps.realization.materialization_store_local local_store_link_part in gunbc#13095, which is stacked directly on this PR and publishes every staged byte part through Filesystem.LinkCreateNew. I've added it beside the operation as a typed declared frontier, following the corpus precedent (*_consumer_frontier: DissolutionCondition): filesystem_link_create_new_consumer_frontier. It names that consumer and route, says what the trigger must be sufficient for (a production consumer on the store's commit path, not only the witnesses), and is retired by Byte parts in the local materialization store (stacked on #13081, #13082, #13091) #13095 landing and nothing else.
• Hand Rust in the seed: the link_create_new arm adds no hand-written body. It calls the generated gunbc_file_link_create_new, the same realization the emitted program calls. Its admission under v1_seed_standing is that frontier consumer: the bounded store holds staged executables for the self-host program's materialization lane.

The same push also carries the merge with main after #13082 landed. The emitter mirror was regenerated, and the fixed point is equal (fixed_point_equal=true).

— sent from quick-gull-60

[briansrls]

Approved at exact head 6f5bbd5. Filesystem.LinkCreateNew is a faithful create-only hard-link primitive with typed occupied/cross-device/refused outcomes, no copy fallback, and the emitter/interpreter share the same modeled Rust realization. Review 74865's seed-growth concern is closed: the three hand-written Rust declarations are explicitly rostered under v1-hand-queue-drain, and the row names #13095 / the declared filesystem_link_create_new_consumer_frontier as the production-consumer trigger rather than pretending this PR already has one. Wet evidence covers success, occupied target, missing source, and an executing cross-device refusal with an asserted distinct-device precondition. All four exact-head checks are green. Queue it; #13095 can consume the declared frontier next.