gitmerge.sh auto-commit bypasses gitpush --only -> sweeps co-workers dirty files onto remote (shared-tree hazard)

REPRO (PLUTO-498, 2026-07-04): coder ran gitpush --only src/lib/not-found-classify.ts. Remote was 8 ahead -> push rejected -> gitpush fell back to gitmerge.sh. gitmerge.sh Auto-commit step IGNORED the --only scope and committed EVERY dirty file in the shared checkout into one Auto-merge commit (dde229e/ff8e463), then pushed it. Result: another lane's uncommitted work published to origin/main without their consent — db 048/049 migration .sql (harmless here, already-applied, but could have been apply-gated), solo-pluto/* config, 4x settings.local.json, public/formulario-practica.pdf. Also swallowed the pusher's package.json bump via newest-wins. SECOND occurrence: PLUTO-491 was the stash-dance variant. IMPACT: on a shared checkout (coder+db+solo share one tree), a rejected --only push silently publishes co-workers WIP -> premature publish / provenance smudge / possible apply-gate violation if a held migration is swept. ASK (design is tool-owner's call, not pre-committed): make the gitmerge rebase-fallback HONOR --only — e.g. stash non---only dirty files before the auto-commit and restore after, OR refuse with a clear message when non---only dirty files exist, rather than sweeping them. Constraint: must not break the legit rebase-over-remote-ahead path for the pusher's OWN --only file. mem: shared-tree-push-hazard. Owner: bin-whey-cc (gitpush.sh/gitmerge.sh live in the sh.git PATH checkout).