A different dcode entry point is winning on PATH than the one we upgraded.
Returned by detect_shadowed_dcode after a successful upgrade so the user
can be warned that a manually launched dcode will pick up the wrong
binary. The startup auto-update's own restart is unaffected: it re-execs
upgraded_bin directly rather than going through a PATH lookup. The most
common cause is a pre-uv install (e.g. a leftover from a previous
pipx/pip-based install) earlier on PATH than the uv tool shims.
A frozen dataclass rather than a NamedTuple (unlike the sibling
DependencyChange) so __post_init__ can enforce the conflict invariant
the type's name promises: an instance only exists when there genuinely is
a shadow. The producer already guarantees this, so the check is defensive
against future direct construction, not a runtime gate on the hot path.
Absolute path to the dcode (or deepagents-code) binary the user's
PATH currently resolves first — the file their next dcode will run.
Reported as the un-followed shutil.which result rather than its symlink
target, since that's the file the user needs to either delete or demote
on PATH.
Absolute path to the bin directory uv installed the upgraded shim into.
Resolved via uv's documented executable-directory precedence (see
_uv_tool_bin_dir).
Console-script name requested from PATH.
Kept separately from shadowing_bin because Windows PATHEXT can make
the latter end in .cmd or .bat, even though uv installed an .exe
shim for the same entry point.
Absolute path to the upgraded console-script shim uv installed.
Resolves the requested entry point within uv's bin directory so
Windows PATHEXT selects uv's actual executable suffix instead of
reusing a shadowing .cmd or .bat suffix. On other platforms, this
resolves the normal shim name directly.
