v0.7.0 — per-backend concurrency caps + page rate-limit detection

The two backends now have separate concurrency policies — because they hit different limits — and the web backend understands chatgpt.com's rate-limit dialog instead of timing out against it.

Per-backend concurrency caps

Backend	Default cap	Why	Override
web	1 (serialized)	The chatgpt.com page surface rate-limits aggressively ("Too many requests"), and all runs share one logged-in Chrome.	CHATGPT_IMAGEGEN_WEB_CONCURRENCY
codex	4	Independent HTTP POSTs, measured safe at 4 concurrent on Plus; capped so big agent fan-outs can't trip the account limiter (previously unbounded).	CHATGPT_IMAGEGEN_CODEX_CONCURRENCY (0 = unlimited)

• Implemented as a cross-process flock slot pool: firing more processes than the cap is safe — excess runs queue (waiters print "waiting…"), and the --timeout budget starts only once a slot is acquired, so queue time is free. A crashed holder's slot is released by the kernel.

"Too many requests" detection (web)

• chatgpt.com's rate-limit dialog renders with the composer still present underneath — previous versions happily submitted the prompt and then hung until timeout. Now:
  • Before submit: fails in seconds with a clear message; auto mode falls back to codex (nothing was billed on the conversation surface).
  • After submit: stops cleanly and says the image may still appear in the conversation — it deliberately does not auto-retry on codex (no double-spend).
  • The per-profile candidate loop aborts immediately too (the block is account-level; trying more profiles just burns ~45s each).
• Verified against a live rate-limited account: detection hit the real dialog, fail-fast in ~5s.

Update

npx skills update chatgpt-imagegen -g
chatgpt-imagegen --version   # should print 0.7.0