gdrive REMOTE backup lane has no object-count instrument - 85 on Drive vs "kept 86-1" on the mount, and nothing ever asserts the remote count

MEASURED 2026-09-12 12:10 UTC during VENUS-406 acceptance, NOT a theory: rclone lsl gdrive:remotedocs/backup/venus returned 85 objects, while venus-db-backup.sh v1.8 prune_lane reported "kept 86-1" for that same directory addressed as the local mount ~/gdrive/backup/venus. The two numbers are readings of the same lane taken seconds apart through two different instruments - the Drive API and the rclone VFS cache - and they do not have to agree, because the mount runs --dir-cache-time 24h --attr-timeout 24h and can be up to a day stale. WHAT IS ACTUALLY UNKNOWN: whether the REMOTE lane prunes at all. prune_lane operates on the MOUNT path, so a delete propagates to Drive through rclone; nothing in this design ever asserts the remote object count, and no run reads the remote except to confirm ONE artifact by name. So an orphan on Drive that the mount never lists would be invisible to every check we now have, forever. THIS IS VENUS-355 SIBLING SHAPE AND MUST NOT BE FOLDED INTO IT (pmmaster ruling 2026-09-12): different lane, different retention mechanism, and folding would let one fix close two findings on one exercise - the shared-function error in another costume. DO NOT ACT ON THE 85-vs-86 GAP AS A DEFECT: it is one sample through a cache documented to lie for 24h, and an agreeing or disagreeing sample is equally consistent with a healthy lane. The deliverable is an INSTRUMENT - count the remote lane directly and compare against what the run believes it kept - not a fix. Depends on nothing; blocked by the fleet-wide token STOP of 2026-09-11 23:57, file-not-start.