Update the graph when the workspace changes

[paracycle]

Status: draft

This is not ready for review. The deletion path knowingly carries two defects, described under
"Known gap" below, and they are the reason this work was split out of #869. This pull request should
own the fix before it opens for review.

Goal

Stacked on #869. That pull request adds the client/server infrastructure and serves the graph as a
boot snapshot, so a file edited after the server starts is still answered from the state it had at
boot. This one reconciles the graph with the workspace before answering a query, which makes
rdx query --server agree with rdx query.

Review #869 first. The diff here is only the reconciliation layer.

What changes

A walk records the mtime of every indexable file. Comparing it with the previous walk gives three
sets: added or changed files go to the indexer, deleted files leave the graph, and the rest are
untouched.

Mirroring the indexer

The walk decides what gets re-indexed, so it has to see the workspace the way the indexer does.
File.directory? follows symlinks and the Rust walker does not, so a link pointing at an ancestor
made the walk descend into the same subtree repeatedly: one ln -s .. sub/loop recorded a single
file 32 times, under paths up to 301 characters.

The rule differs by depth, and both halves matter:

• Graph#workspace_paths uses File.directory? on the workspace's own children, so a symlinked
  directory there becomes an explicit root, and the Rust walker traverses an explicit root.
• Below that, a symlink is never followed.

Four tests pin this against the Rust tests that describe the same behaviour.

Attributing an index failure

index_all reports opaque messages for a whole batch, so a failure cannot be attributed to a file.
The graph cannot answer it either, because a failed update leaves the previous document in place. A
failing batch is therefore halved until each failure sits alone. A batch indexes far faster per file
than single calls do:

Strategy	1081 files, one unreadable
Halving the batch	21 calls, 75 ms
One file at a time	1081 calls, 311 ms

A file that failed keeps its previous mtime, so the next request tries it again. Recording the new
one would call a file the server never read "fresh" for the rest of its life. The same rule covers
the initial index, which is why build_graph returns the errors it saw and drops the roots that do
not exist: workspace_paths names gem directories an install may not have, and those phantom errors
would hide the real ones.

Not erasing what it cannot see

A directory the walk cannot read contributes no entries, and reading that silence as "every file
below here was deleted" erased whole subtrees. Two cases reach it: a directory that cannot be read at
all, and one that is readable but not searchable, where each_child lists the names and every
lstat is refused. Both keep their entries. A directory that is really gone still takes its files
with it.

The rescues name the errors that describe one path, including ELOOP, which a self-referential
symlink raises from File.mtime after lstat called it a plain file. A resource failure such as
EMFILE is deliberately absent: swallowing one would empty the walk, and the refresh would then
erase the graph.

Known gap: deletion and URIs

This is what keeps the pull request in draft.

Graph#delete_document is keyed by the document's canonical URI, and the server has a filesystem
path. uri_for reproduces that mapping in Ruby, and it does so imperfectly:

• It does not canonicalise, so under a symlinked path the strings differ, remove finds nothing, and
  the deletion silently does nothing. Deleted files keep answering queries until the server restarts.
• URI::File.build raises URI::InvalidComponentError for a path containing a space, so the first
  refresh that sees a deletion fails the query.

Both are confirmed, not suspected.

This is the only place the server needs a URI at all. Rust builds the document URI from a path it has
already canonicalised and simplified (path_helpers::resolved, then Url::from_file_path), so the
correct fix belongs at the graph API: either delete_document_at(path), or an exposed canonical
path-to-URI function. Test::Helpers::Context#uri_to carries the same two lines and the comment
TODO: This has to go away once we have a proper URI abstraction, which is the same gap.

Tests

test/server/core_test.rb covers the walk, the attribution and the preservation rules;
test/server/integration_test.rb covers a change and a deletion through the real executable.