fix(truth): stop resolving redacted worktree labels as filesystem paths

[saagpatel]

What

Truth validation no longer calls Path.resolve() on values it cannot treat as filesystem
paths. A redacted worktree label compares as itself; an absolute path still compares by
resolved location.

Why

The nightly portfolio job failed twice on 2026-08-11, at 12:39Z and 15:20Z, after
succeeding at 09:03Z. It died inside truth validation with a bare FileNotFoundError and
no message naming a file, so the receipt recorded only that generation had failed.

A worktree outside the observed workspace is recorded as an opaque label,
external-worktree-2 and so on, deliberately, so paths outside the workspace never reach
published output. The duplicate-path check then handed every recorded worktree path to
Path.resolve(), labels included. In the last published snapshot 98 of 434 worktree
entries are labels rather than paths.

Resolving a value that is not absolute makes Python ask the operating system for the
process's working directory so it can build an absolute path. Two consequences, and the
first one was true every single day:

• For a label the answer is meaningless. It silently invents a path under whatever
  directory the process started in, so the dedup comparison was comparing fabrications.
• Once that directory has been deleted underneath the process, the same call raises
  FileNotFoundError instead. That is the crash.

The traceback bottoms out at posixpath.py:412, which is cwd = os.getcwd().

How

One helper decides identity: absolute values resolve, everything else is compared
literally. Applied at the dedup check and at _same_repository_path, which had the
identical exposure.

Behaviour for real paths is unchanged. Two spellings of one directory still compare equal,
including through a symlink, and a label never compares equal to a real path.

Testing

Full suite: 3513 passed, 2 skipped. ruff check src/ tests/ clean.

The regression test deletes the process's working directory and asserts both halves: that
the standard library really does raise under that condition, and that the guarded
comparison does not. That first assertion is the point of the test rather than decoration.
Without it a later reader cannot tell whether the guard is load-bearing or a leftover, and
the test would keep passing if the guard were removed.

Risk / Notes

• The nightly job runs a pinned checkout, currently 907780d, which predates the package
  namespace change. This fix does not reach production until that pin moves, and moving it
  is a separate governed step.
• _is_within has the same shape of exposure but only ever receives real paths, so it is
  left alone rather than pre-emptively widened.