fix(stream): expired model lock masks account lock, and dropped generated images (#3516, #3521) - #3879

Both addressed in b75fcdd9, rebased onto 1fe586bb (v0.5.112). Thanks for running it — one of the two asks landed somewhere slightly different from where you aimed it, and I'd rather say so than quietly patch something else.

The images test — exactly as asked

stream-keeps-trailing-generated-image.test.js, 4 tests. The existing one called hasValuableContent directly, which proves the predicate and nothing about the stream that consults it. These drive a real Gemini→OpenAI transform with the image part as the last thing the provider sends:

Reverting the delta.images line turns all four red. I checked that rather than assuming it.

The lock helpers — the divergence is scope, not expiry

I went to add the per-key expiry treatment and found it is already there: getEarliestModelLockUntil has if (t <= now) continue. So that part needed nothing.

But you were pointing at something real one level over. isModelLockActive(c, model) is model-scoped; getEarliestModelLockUntil(c) is connection-wide, so on a connection locked for two models it returns the unrelated model's expiry — and both retry-timing call sites in auth.js used it:

const lockedConns = connections.filter(c => isModelLockActive(c, model));
const expiries = lockedConns.map(c => getEarliestModelLockUntil(c)).filter(Boolean);

A connection locked for claude-fable-5 until 10:00 while holding another model's lock until 09:30 therefore advised a retry at 09:30. The retry hits the same lock and fails identically — one wasted upstream request per caller, surfaced to the user as a second rate-limit error. The debug line beside it printed modelLocked(<model>) until <other model's expiry>, which is how I convinced myself it was real.

getModelLockUntil(connection, model) is the time-valued twin of isModelLockActive: the same two keys, the same getModelLockKey normalisation so a null or absent model resolves account-wide in both, and the later of the two gating expiries — the connection frees up only once both have passed, so returning the earlier one is the same bug in a different direction.

I did not widen getEarliestModelLockUntil, deliberately. "When does anything on this account free up" is the right question for a per-connection cooldown badge, and making the scope depend on whether a second argument was passed would reintroduce exactly the undefined-versus-null divergence this PR already fixes one of. Both of its callers wanted the model-scoped question and now ask for it by name.

5 new tests in model-lock-precedence.test.js, including one that walks 8 lock shapes and asserts getModelLockUntil(...) !== null equals isModelLockActive(...) for every one — so the two cannot drift apart again without a red test.

Mutation-checked, since the subtle wrong version here passes a naive test:

Verification

82 failing tests on this branch and the same names on master-with-these-tests — comm on the sorted name lists is empty in the branch-only direction, so this adds no failure. (First run writes 138 snapshots, so only the second run's names are usable.) The 11 extra failures in the master-source run are these new tests plus the existing image one, all red without the fix, which is the bulk version of the mutation table above.

Also re-checked against current master before claiming the commits are still needed: hasValuableContent still has no images branch, and isModelLockActive is still connection[key] || connection[MODEL_LOCK_ALL]. Neither has been fixed upstream in the meantime.

The three commits remain independent — the new one is fix(fallback): scope retry timing… and can be dropped on its own if you would rather take it separately.