Fix/scan into link mount

[marcusrognes]

Summary

In my workflow i use links quite a bit, my structure is usually this:
/assets <- linked repo
/doc <- other linked repo
/engine
/etc...

If I make changes in assets or doc from this repo, and run lore status --scan <path> or lore stage --scan <path> on a path inside one of those mounts that the repository doesn't already track, like a new file, or a new directory, the command fails and the local repository is left unusable:

[Error] computing diff against filesystem: Node not found
  at lore-revision\src\state.rs:6803 - scan add: parent directory node missing for nested add
  at lore-revision\src\repository\status.rs:974 - computing diff against filesystem

On a larger mount it comes out as Invalid block index: N instead.

After that, plain lore status no longer runs, and lore link list reports fewer mounts than the repository has.

lore repository verify still reports "Verified repository state integrity" throughout, so nothing warns you that it is broken.

How to reproduce

With a repository mounted at assets/, add a file the parent doesn't track yet and scan its path:

mkdir assets/untracked
echo added > assets/untracked/added.txt
lore status --scan assets/untracked/added.txt

[Error] computing diff against filesystem: Node not found
  at lore-revision\src\state.rs:6803 - scan add: parent directory node missing for nested add

you can also check out f53ea99 and run the scripts/test/regression/test_link_scan_stage.py test.

The fix:

What it does:

A --scan that targets a path inside a link mount now resolves that path in the repository that owns the mount, instead of against the parent repository's state. ensure_scan_dir_chain crosses a link segment and continues in the linked state, the same crossing the whole-tree walk already performs, and hands the resolved parent node to the add, so the node is created where it belongs. Two supporting guards: an add never uses a NodeID owned by another state, and a failed add or dirty-mark aborts instead of being swallowed and continuing over already-mutated state.

What it prevents:

The local corruption. Before, the scan added under a foreign NodeID, which either named a block the parent state doesn't have (Invalid block index: N) or silently hit an unrelated node at the same coordinates, after mutating.

What it allows:

Adding new content inside a mount from the parent working copy, with a path-targeted scan, status --scan /, stage --scan /, and the change lands in the linked repository. That includes the case that had no workaround at all: a mount whose tracked content sits only at its root, with no already-tracked subdirectory to name, previously reachable only by cloning the linked repository and committing there.

This might fix some #90 style issues, not sure about that exact case tho.

Checklist

• Linked to an issue above, or explained why none applies
• Every commit carries a Signed-off-by: line (DCO -- see CONTRIBUTING.md)
• cargo +nightly fmt --all produces no changes
• cargo clippy --all-targets -- -D warnings --no-deps passes, same two errors on main, none added (see note)
• cargo test passes
• uv run pytest passes, full suite on Windows; test_nodeblock (slow, not in CI's -m smoke) needs --timeout=0 locally (see note)
• Docs under docs/ updated where behavior changed
• If this change is large or cross-cutting, an LEP has been filed first

clippy: this command does not pass on main either. On a pristine f4f344d,
clippy 0.1.96 reports exactly two errors, both outside this change:
nonminimal_bool at lore-revision/src/state.rs:8568 and large_enum_variant
on PathListingResult at lore-revision/src/util/fs.rs:630. This branch reports
the same two and no others.

pytest: full uv run pytest scripts/test on Windows, release binaries, -n 8:
everything passes except scripts/test/test_nodeblock.py::test_nodeblock, which
exceeds the 600s per-test timeout under parallel load, it is @pytest.mark.slow
and so outside CI's -m smoke job. It passes serially with --timeout=0, at the
same wall time as on main. No assertion failure anywhere in the run.