fix(switch): keep name-conflicted files that are in the target view's inherited state

[graywolf336]

Summary

A view switch deleted files that were in the target view's inherited state when those files had a materialization name-conflict (two inodes visibly claiming the same path). In the reported incident, switching views repeatedly removed atomic-core/src/change/publication_gate.rs, atomic-core/src/pristine/txn/write/view.rs, and atomic-core/src/pristine/audit.rs from the working tree — breaking compilation (E0583 file not found for module …) and leaving a perpetually-modified state that blocked every subsequent switch with "Working copy has unrecorded changes".

Root cause

Repository::switch_view computes old/new visible file sets via visible_file_paths (materialize.rs) and Phase 2 removes old_files − new_files. But TREE is a single-valued path→inode index: when a second inode visibly claims the same path (a name conflict), visible_file_paths only sees the single TREE binding — whose introducing change may not be in the target view's visible set, even though the path is in the target's inherited state (via the other binding). The switch therefore classified a conflicted-but-inherited file as "old view only" and deleted it.

The materializer already walks REV_TREE to recover every inode claiming a path for its name-conflict detection (materialize.rs:485-531); visible_file_paths lacked the same recovery.

Fix

visible_file_paths now also walks REV_TREE and keeps a path when any inode binding it has its introducing change visible on the view (mirroring the materializer's conflict detection). Paths with a single binding behave identically.

Verification

• New regression test switch_to_inheriting_child_keeps_name_conflicted_file (atomic-repository/src/repository/tests/switch_file_loss_tests.rs):
  • fails before the fix: switch deleted a name-conflicted file that is in the child's inherited state
  • passes after: the file survives the switch with its conflict markers intact
• Full atomic-repository suite: 872 passed, 0 failed
• cargo fmt --check + cargo clippy -D warnings: clean

Impact

• No more working-tree corruption (file deletion) on view switch
• No broken compilation from modules deleted out from under mod.rs
• Per-intent view workflow unblocked
• No wire/format/storage changes

[graywolf336]

Relationship to #206

These two are complementary halves of the same name-conflict story, not duplicates:

• This PR (fix(switch): keep name-conflicted files that are in the target view's inherited state #199) is the view half. Its job: a view is a filter over the graph, so visible_file_paths must equal what the view's filter renders — when two inodes claim one path (name conflict), the conflicted path must stay in the target view's file set, and switching must never delete it. READ side.
• Fix/occupant baseline visible owners #206 is the graph half. Its job: once that state is kept, binding-level operations on that path (del_tree_binding, deferred-tree ops, occupant baselines, switch transactionality) must never unlink the sibling inode. WRITE side.

Together: #199 keeps the conflict visible across switches; #206 keeps it safe to edit and resolve. #199's code doesn't overlap #206's files, but both touch the same problem area — see my longer note on #206.