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

@@ -20,6 +20,16 @@
 # Only escalates to the scary abort-and-notify when the count is genuinely low AND nothing
 # is actively rescanning.
 #
+# Cache-first, both layers (2026-07-17). The artist 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-artist trackFile 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() so lidarr_missing_art.sh,
+# running later in the same nightly window, can read it instead of repeating the same walk.
+# 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
 # ==============================================================================================