tracker_not_initialized recovery re-suggests pm init even when a --pm-path tracker exists — following it silently splits workspace state (GH-501 residue) #592

Version: pm 2026.7.18

Follow-up to closed GH-501 (which fixed discovery for positional pm init <path>): when a tracker was initialized with --pm-path <custom>, subsequent bare commands in the same directory still fail with tracker_not_initialized, and the error's guidance re-suggests pm init — which, if followed, creates a second tracker at <cwd>/.agents/pm and silently splits workspace state.

Repro

$ cd /tmp/ws && pm init --pm-path /tmp/ws/.pm --id-prefix uxt
# init's next_steps correctly prefix every command with --pm-path — good
$ pm list
Error: Tracker is not initialized

What happened:
  Tracker is not initialized at /tmp/ws/.agents/pm. Run pm init first.
...
Next steps:
  - Run "pm init", then rerun your original command.

/tmp/ws/.pm/settings.json exists one directory entry away from the probed path.

Expected vs actual

• Expected: the tracker_not_initialized recovery bundle should (1) mention that discovery only probes .agents/pm and that --pm-path <path> / PM_PATH select custom roots, and ideally (2) detect an existing non-default tracker nearby (e.g. <cwd>/.pm, <cwd>/*/settings.json one level down) and say: found a tracker at /tmp/ws/.pm — rerun with --pm-path /tmp/ws/.pm or set PM_PATH.
• Actual: "Run pm init first." An agent that complies gets a second, empty tracker at .agents/pm; from then on both trackers "work" and items land in whichever the flags select — divergence with no error anywhere.

Why it matters for agents

Custom --pm-path is exactly what agents use for isolated/throwaway workspaces (and what init's own next_steps teach). The current error turns one forgotten flag into silent state-splitting, because the advertised recovery action is the one action that makes it worse.