bug: restored or moved .planr state keeps stale absolute paths and doctor passes

[regenrek]

Summary

Moving or restoring a repository together with its .planr directory leaves absolute project and plan paths pointing at the old machine. Planr continues to open the local SQLite database and planr doctor --json reports db_status: pass, but filesystem-backed plan commands fail because they consume the stale absolute plans.path.

Planr 1.5.1 exposes no supported relocation command.

Environment

• Planr 1.5.1
• macOS arm64
• Source path: /Users/kregenrek/projects/vergabeApp
• Restored path: /Users/devbook/projects/vergaberadar
• Restore method: copy the complete .planr directory, including planr.sqlite

Reproduction

1. Initialize a project and create a product plan.
2. Move/copy the repository, including .planr, to a different absolute path.
3. From the new repository root, run:

planr project show --json
planr doctor --json
planr plan check <plan-id> --json

Actual behavior

• project show reads the restored DB but returns the old projects.root_path.
• doctor reports the DB/project as passing.
• plan check reports plan path missing, even though the plan exists under the new repository's .planr/plans.
• plans.path and items.plan_path retain the old absolute prefix.
• There is no project relocate / project move command.

Example:

{
  "message": "plan path missing",
  "file": "/Users/kregenrek/projects/vergabeApp/.planr/plans/product/..."
}

while the same plan physically exists at:

/Users/devbook/projects/vergaberadar/.planr/plans/product/...

Why this is functional

The 1.5.1 code constructs PathBuf::from(&plan.path) in plan check/refine/export and other filesystem-backed flows. The stored path is therefore not display-only metadata.

Expected behavior

Either:

1. Store repository-relative paths for all files under .planr; or
2. Provide an atomic, supported command such as:

planr project relocate --to "$(pwd)"

that updates projects.root_path, plans.path, items.plan_path, and any other operational references consistently.

planr doctor should detect when the active project's stored root differs from the current repository root and fail or provide the relocation command.

Safety requirements

• Atomic transaction
• Dry-run / JSON preview
• Refuse ambiguous multi-project databases
• Preserve historical log/event/evidence text
• Create or recommend a DB backup before mutation
• Verify every rewritten path remains under the current repository root

Additional finding

The restored database also contained two active project rows created seven seconds apart. Only the newer project owns plans/items. In 1.5.1, project init uses a fresh random ID with INSERT OR IGNORE, so repeated init is not idempotent because the primary key never conflicts. This may deserve a separate guard/issue, but it is independent of the relocation failure.