Update headers on today's arr-caching changes

Comment-only. Headers on the scripts touched during today's caching work
(cache-first fetches, write-through per-item cache, single-walk
consolidation, movieFile-embedded fix) still described pre-change
behavior. Also brought common.sh's top-level cache doc block current --
it was written for the single-consumer 2026-07-16 state and didn't
mention the tmpfs move, the write guard, or the 15+ consumers that now
go through it.

Arrs_Stack/radarr_cleanup.sh

@@ -18,6 +18,17 @@
 # false-alarm abort. Mirrors the same fix built for lidarr_cleanup.sh 2026-07-16 after
 # a whole-library rescan there made trackFileCount read 22% of normal mid-scan.
 #
+# Cache-first movie list, no per-movie API calls at all (2026-07-17). The movie list comes
+# from the shared tracked-data cache via arr_get_tracked_data() — fresh (kept warm every
+# 30min by arr_cache_prefill.sh), live fetch as fallback. Radarr is structurally different
+# from Lidarr/Sonarr here: its movie list already embeds movieFile.path directly on every
+# hasFile=true entry (confirmed live, zero exceptions across the full library), so there's
+# no separate per-movie moviefile?movieId=X walk needed at all — what used to be up to 2896
+# individual API calls is now a jq filter over data already in hand. The filesystem is
+# walked once per run, not twice — classification records which paths are eligible for
+# deletion as it goes, and the delete pass (once the size-threshold check below passes)
+# just acts on that list instead of re-walking and re-classifying the whole tree.
+#
 # ==============================================================================================
 # OPERATIONAL MODEL
 # ==============================================================================================