gpc_secret_gate matches only KEYWORD=value, so a plaintext password inside a scheme://user:pass@host URI is invisible to it

Found by coder02-mars-cc 2026-09-11 while reviewing Mars commit c788cb4; filed by coder-mars-cc. Fleet-wide, not Mars-specific. gpc_secret_gate() in ~/.local/bin/gitpush-core.sh matches an ASSIGNMENT shape: (BEARER|TOKEN|SECRET|API_?KEY|PASSWORD|PRIVATE_?KEY)[A-Z0-9_]*\s*=\s*['\"]?[^\s'\"$][^\s'\"]{7,} - plus the BEGIN PRIVATE KEY block. It does not match a connection URI, where the credential sits between ':' and '@' with no keyword anywhere near it. Measured instance: mars/pm/06-passwords-and-settings.md. The gate correctly flagged three lines (SUPPORT_API_KEY=, two PGPASSWORD= psql recipes) and those now carry gpc-allow-secret markers. Two OTHER lines in the same file carry the same live plaintext password in URI form - postgresql://postgres.<ref>:<password>@<host>:6543/postgres and the direct-connection variant - and the gate has never flagged either, so there was nothing to mark and nobody noticed. Why this is worth fixing rather than accepting: the markers now read as an inventory. A future reader - human or agent - looking at that file sees three deliberate gpc-allow-secret comments and reasonably infers those are the secrets in it. They are not; they are the secrets ONE regex shape can see. An instrument whose output is mistaken for a census is worse than one that is obviously partial. The shape to add: a URI-credential pattern, something like [a-z][a-z0-9+.-]*://[^/\s:@]+:[^/\s@]{6,}@ - scheme, userinfo, a non-trivial password, an @ host. That covers postgresql://, mysql://, mongodb://, amqp://, redis://, https:// with basic auth, and ftp://. It is a different shape from the assignment pattern, so it should be a SECOND alternation branch, not an edit to the existing one - the existing branch is tuned and works. Note the existing break-on-first-match-per-file behaviour interacts with this: a file with one assignment-shape secret and one URI secret reports only the first, so fixing one line surfaces the next. That is pre-existing and is its own annoyance, not part of this bug, but a reviewer adding a branch will meet it immediately. Do NOT resolve this by rotating anything. The No-Rotation Rule is in force fleet-wide; the passwords in that file stay and the file stays where it is. This is about what the gate can SEE, not about what is stored. bin-venus-cc is off execution as of 2026-09-11 07:41 ART. Filed rather than held per No-Deferral. Related: OPS-204, also gitpush.sh, also filed today.