fix(indexbuild): repair the one database a squash cannot reach

The index job's /cache volume is a real YJ_HOME that outlives every
run, so plan 013's reshaped audio_files met a database still in the
old shape: `CREATE INDEX ... album_id` against a table without that
column, on every launch. "Delete and rescan" is the squash's answer
and is free everywhere except here, where half the file is the catalog
and deleting it costs ~205GB of downloading.

indexbuild now drops every table datamap does not classify as Cache
before the schema is applied. Nothing scans, plays or authors in that
database, so its non-catalog half is empty by construction and a shape
the schema stopped describing is pure liability; the catalog is never
touched.

TestRetireLibraryTables reproduces the failure symptom-first: build
the real schema, put audio_files back the way the volume had it,
assert the open fails, then assert the repair makes it open with the
catalog row still there.

CLAUDE.md

@@ -233,6 +233,19 @@ rather than renaming them.
   the drift it caused before — `sql/schemas/` and the migrations
   disagreed, and sqlc generated against the stale one.
 
+  **What that costs an existing database is that it does not open**, and
+  "delete and rescan" is the answer (plan 013, open question 1) — free
+  for everyone except one machine. The index job's `/cache` volume is a
+  real `YJ_HOME` that survives between runs, and half of it is the
+  catalog: deleting it means re-downloading ~205 GB. So `cmd/indexbuild`
+  repairs it instead (`staleschema.go`), dropping every table `datamap`
+  does not classify as `Cache` **before** the schema is applied. Nothing
+  scans, plays or authors in that database, so its non-catalog half is
+  empty by construction and a shape left over from an older schema is
+  pure liability. 013's reshaped `audio_files` failed every run of that
+  job on `CREATE INDEX ... album_id` against the old table until this;
+  `TestRetireLibraryTables` reproduces exactly that, symptom first.
+
   **The local library is shaped like files, not like MusicBrainz.**
   `audio_files` carries its own tags — title, artist credit, track and
   disc numbers, year, composer, the recording MBID — and points at two