provider: an account refused for quota has its allowance read again a…

[TryWorld2026]

provider: an account refused for quota has its allowance read again at once, instead of the share it last said being trusted for a minute

What is wrong

StaleAllowance dropped the account out of loginUsageCache and zeroed when
its allowances were last read, and left the reading itself where it was. So
right after the vendor refused an account for its quota:

• Allowances() answered the share the vendor had last said, and
• a reading begun before the refusal came back and was kept, so the stale
  figure was trusted for the minute after.

The menu bar's "account in use" and the routing trace kept showing an account
the vendor had just refused for its quota.

What changed

StaleAllowance now goes through forgetAllowance, the same helper a renewal
uses: the account leaves the set of allowances last read (so the next read
fetches), and a reading in flight is dropped rather than kept when it returns.

The change is only the two lines that hand-wrote usedCache.at[agent] = time.Time{}; the guard, the log line and the entry's shape are as they were.

Semantic change (Providers and accounts)

• Before: an account refused for quota kept the last reading the vendor gave,
  which Allowances() and the routing trace answered with for up to a minute.
• After: the reading is forgotten, so the next Allowances() reads the account
  again and the routing sees what the vendor just said.
• Reference: docs/subsystems/providers-accounts.md;
  implementation StaleAllowance in internal/provider/routing.go.

Verification

• TestStaleAllowanceForgetsTheReading fails without the change
  (still read as [{12 ...}]) and passes with it: the held reading is asked
  again and answered with the account used up.
• go test -tags nogui ./internal/provider (the full package), go vet,
  gofmt on LF-normalized copies of the changed files (the worktree is CRLF),
  and the GOOS=windows/darwin/linux builds.