tooling: scheduled profiles/full-sweep list posts+reels by browser (chrome-sync per profile/tab, early stop for weekly); GDL_LISTING=api fallback; reels-tab sweep note in MANUAL-RUN

TOOLING.md

@@ -327,9 +327,15 @@ newest-first, so after 2 scroll rounds in a row that turned up nothing unarchive
 (`--max-known-rounds`, round 1 exempt because pinned posts sit on top) there is nothing newer to
 find. First run, `heejin`: 3 scrolls, 36 posts seen, 30 already held, 6 new.
 
-Same caveats as reels: it drives the signed-in Chrome on `:9222`, so it is by hand, not on a
-timer. Once a gallery-dl release fixes the listing, `run-profiles.sh` covers posts again and
-this goes back to being a fallback.
+**Scheduled since 2026-10-23.** `gdl-cron.sh profiles` and `full-sweep` now list posts *and*
+reels this way: gallery-dl only does `--only stories,highlights`, then `chrome-sync.sh` runs per
+profile for the `posts` grid and the `reels` tab (both tabs needed: on 10-23 only 3 of heejin's
+114 reels were in the main grid). `profiles` uses the early stop (2 known rounds) on both tabs,
+and `full-sweep` scrolls every grid to the bottom. A failed browser step fails the run, which
+shows on Healthchecks. This reverses the earlier "by hand only" decision on purpose: the API
+listing is broken and the owner chose the browser. The trade-off is that unattended runs now
+need Chrome up on `:9222` with a live session, and they open and close their own tabs in it.
+`GDL_LISTING=api` restores the all-gallery-dl run once a release fixes gh#9829.
 
 **Deploy scripts atomically, never in place.** bash reads a script as it runs, so overwriting
 `gdl-cron.sh` under a running sync makes bash resume at the same byte offset in the *new* text.
@@ -836,11 +842,11 @@ after — left behind for inspection, same as `gdl-cron.sh`'s `staging-*`.
 Verified end to end against `zindoriyam` on 2026-08-27: 26 reels found on the
 page, 10 new ones fetched and published cleanly on the first run.
 
-**Not wired into `gdl-cron.sh` or the timers.** Both scripts drive your
-actual browser session rather than firing a background request, and are
-slower by design (real scrolling, not an API call) — both good reasons not
-to run this unattended without deciding that deliberately. Today it is a
-per-profile, by-hand tool only.
+**Not wired into `gdl-cron.sh` or the timers** (as of 2026-08; **superseded 2026-10-23**: the
+weekly and quarterly runs now use the browser listing, see "Posts grid by browser" above). Both
+scripts drive your actual browser session rather than firing a background request, and are
+slower by design (real scrolling, not an API call), both good reasons not to run this
+unattended without deciding that deliberately.
 
 For all six ARTMS profiles in one go, `~/gdl/run-reels-all.sh` just calls
 `reels-sync.sh` once per profile in `artms_account_links.txt`, same