Registration: resolve interpreter and Python paths before persisting an app #49

Problem

registry.register() accepts --prefix and repeatable --pythonpath values, but stores them without converting them to absolute paths.

• registry.py lines 124–133: python_for(prefix) and PYTHONPATH are built from the original arguments.
• registry.py lines 138–149: prefix, python and pythonpath are persisted in their original form.
• registry.py lines 396–405: load_entries() resolves the stored interpreter relative to the host's working directory.
• client.py lines 162–177: the worker inherits the stored pythonpath entries.

A registration such as labconstrictor-tools register --name demo --prefix .venv --module demo_lc_tools --pythonpath src can succeed from the project folder but disappear from list or load a different module when Fiji/Napari starts elsewhere.

Reproduction

1. From an app project directory, register an app using a relative existing interpreter prefix and/or relative --pythonpath.
2. Confirm registration succeeded and the JSON contains relative paths.
3. Change to a different working directory; run labconstrictor-tools list / doctor or launch a graphical host.
4. The interpreter path no longer resolves (or the worker's module search path points to the wrong directory).

A focused pathname reproduction of the current logic confirmed that Path("venv/bin/python").exists() changes from true to false when only the current directory changes.

Proposed fix

Normalize prefix, interpreter path and each pythonpath to absolute paths at registration time, before probing or generating the schema, and store those canonical paths. Ensure unregister --prefix still compares equivalent paths correctly. Do not reinterpret existing paths relative to whichever host launches later.

Acceptance criteria

• A test registers from directory A with a relative prefix and --pythonpath, changes to B, then confirms list, doctor and a tool run work.
• The registry JSON stores paths that are independent of the caller's CWD.
• Existing absolute-prefix registrations and system/shared registries remain supported.

Priority: P2 — registered applications can disappear or import the wrong code depending on the host's working directory. Static source review plus a focused pathname reproduction; no full host integration run.