fix(paths): strip legacy "data/" prefix when resolving stored paths

0.3.0 sometimes stored relative media paths with the data-dir name baked in
(e.g. "data/profiles/<uuid>/sample.wav"). resolve_storage_path joined those
directly with _data_dir, producing "<data_dir>/data/profiles/..." — a
spurious double nest that breaks file reads after upgrading to 0.4.0.

The 0.4.0 startup migration didn't catch it because resolve_storage_path
produced the buggy double-nested path, to_storage_path saw "data" at the
first (legitimate) index, and the normalized value matched the stored value
so the row was skipped.

Strip any leading "data/" component before joining. This unblocks runtime
reads and lets _normalize_storage_paths rewrite the affected rows on next
startup — no manual migration needed.

Fixes "No such file or directory: '<data_dir>/data/profiles/...'" and
associated 404s on GET /audio/<id> after upgrading from 0.3.0 to 0.4.0.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

backend/config.py

@@ -89,6 +89,14 @@ def resolve_storage_path(path: str | Path | None) -> Path | None:
 
         return stored_path
 
+    # 0.3.0 records sometimes stored relative paths with the data-dir name
+    # baked in (e.g. "data/profiles/..."). Joining those directly with
+    # _data_dir produces a spurious "<data_dir>/data/profiles/..." nest.
+    if stored_path.parts and stored_path.parts[0] == "data":
+        stored_path = (
+            Path(*stored_path.parts[1:]) if len(stored_path.parts) > 1 else Path()
+        )
+
     return (_data_dir / stored_path).resolve()