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/sonarr_cleanup.sh

@@ -19,6 +19,17 @@
 # lidarr_cleanup.sh 2026-07-16 after a whole-library rescan there made trackFileCount
 # read 22% of normal mid-scan.
 #
+# Cache-first, both layers (2026-07-17). The series list itself 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. The per-series episodefile walk below still
+# always fetches live (that's the actual disk-truth this script's delete decisions depend
+# on), but write-throughs its result to arr_item_cache_write() for any future script that
+# needs Sonarr's per-episode data — no second consumer exists yet, unlike Lidarr's
+# lidarr_missing_art.sh, but the data's there once one does. 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
 # ==============================================================================================