Path identity

One directory can be spelled several ways. git prints worktree and repository paths with forward slashes and its own long, on-disk spelling (C:/Users/LongUserName/repo/ops-<wu-id>). Node builds C:\Users\LongUserName\repo\ops-<wu-id> from a directory listing, and the working directory can arrive as c:\... or with an 8.3 short name (C:\Users\LONGUS~1\...). Windows treats all of these as one directory. LumenFlow therefore never compares filesystem paths as strings.

The rule

Every equality or containment check between filesystem paths uses one primitive from @hellmai/lumenflow-kernel/primitives:

Function	Use it to ask
`samePathIdentity`	do two paths name the same location?
`isPathWithin`	is a path inside a root (or the root itself, `allowEqual`)?
`pathIdentityKey`	what key should a Set or Map use for this path?

The key resolves the path with the platform path module (git’s forward slashes become the native separator), canonicalises it through the native realpath (8.3 names, junctions, symlinks and on-disk case; a path that does not exist yet uses its nearest existing ancestor), and folds case on Windows. Keys on Linux and macOS stay case-sensitive. A key is for comparison only.

What it protects

wu:prune and lumenflow doctor recognise every registered worktree whatever its spelling. Before deleting an orphan directory, wu:prune re-reads git’s worktree registration and refuses any directory git still lists, in any spelling; if it cannot read the registration, it deletes nothing.
wu:claim, wu:done, wu:rebase, wu:repair, wu:recover and wu:release match the worktree git registers with the path LumenFlow computed, including from a shell whose working directory uses a short name or a different drive-letter case.
lumenflow:upgrade recognises the main checkout from any of its subdirectories, and deps:add recognises a Windows working directory inside a worktree.
A failing gate produces one failure signature whichever spelling of the worktree root the tool output uses.