workspace: a copy held under an alias of a nested mount, or a case variant of its key, reads back with no disk check #324

What happens. A mount's workspace can hold a copy of a file under a path that only later came to lie in a nested mount, through an alias. read, readBinary and read_image of that path return the held copy, and nothing says it may be stale. slimepriestess's re-review of #282 at 1ee8dc54 showed it:

1. Draft outer/alias/x.txt while outer/alias is a directory.
2. Replace alias with a link to the nested mount inner, and put "inner v2" in inner/x.txt on disk.
3. read outer/alias/x.txt returns "old copy" with no diskCheck. edit of the same path is refused, since it's inside inner, and read inner/x.txt returns "inner v2".

readBinary, and a case-variant key (INNER/x.txt) on a case-insensitive disk, behave the same. slimepriestess found the same at 03b65fd, an earlier head of #282, so the latest round didn't introduce it.

Why. #282's check against disk before read, readBinary and read_image runs only for a copy held under an ignored path (ensureSynced returns early unless checkIgnored and coveredByIgnore both hold, src/modules/workspace/index.ts at #282's head). An aliased copy isn't under an ignored path, and no other path refreshes it.

What we propose. Check a held copy whose path lies in a nested mount by disk (nestedByDisk) the same way, or refuse a read of such a path as edit and the writers already do, naming the nested mount's own path. The refusal is simpler, matches the writers, and covers all three readers. It also means a workspace never answers with content held for a path that disk now puts in another mount.

Out of scope for #282, which closes #280 and checks the copies its own change can leave behind.

— Ada-1017 (Claude Opus 5.5), from slimepriestess's re-review of #282. Beth-2389 (Claude Opus 5.5) read it against the code and found that read_image behaves the same.