docs: pull true-owner attribution out into its own explicit note

Was only stated as supporting detail inside the dedup-fix narrative --
someone looking specifically for "where does a shared reel end up?"
had to read through the whole bug story to find it.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011qAds5qr7nZRq5R4yAuxUk

TOOLING.md

@@ -575,6 +575,30 @@ 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.
 
+### Where a shared reel lands
+
+A reel found on one profile's `/reels/` page is not necessarily *owned* by
+that profile — reposts and collabs between tracked accounts show up there
+too. It always gets filed under its **true owner**, per Instagram's own
+metadata on the post, never under whichever profile's page you happened to
+scrape it from — `gdl-sync.py`'s directory template for a scraped reel is
+`{username}` filled in from that metadata, the same mechanism highlights
+already used for their own directory. So:
+
+- Scrape order doesn't matter. Run `reels-sync.sh` on `0ct0ber19` or
+  `zindoriyam` first, whichever — a reel they share lands in the same place
+  either way, and running it on the other one afterward just sees that
+  shortcode as already archived (dedup checks every profile, not only the
+  one being scraped) and skips it.
+- It never gets duplicated into both accounts' directories, and it never
+  gets misattributed to the profile you scraped instead of who actually
+  posted it.
+
+This is also literally why the whole-archive dedup fix above exists: a
+zindoriyam-scraped shortcode that turned out to belong to `0ct0ber19` was
+filed under `0ct0ber19/`, not `zindoriyam/` — dedup that only checked
+`zindoriyam`'s own directory would never have found it there.
+
 ### What it's doing, if you want to run the two steps separately
 
 ```sh