End-of-iteration queue summary: make the post-design 'work is queued, not started' state explicit

Problem

When a --once iteration ends with a design session, the process exits right after filing sub-issues. The operator-facing story stops at "decomposed into 8 sub-issue(s)" — nothing says the queue now has 8 eligible issues; run gloop again to start implementing. In the fishtank experiment this boundary produced a ~30-minute stall: the design landed, the loop exited, and the human driver was left watching a silent repo, unsure whether gloop was grinding or done.

(The same applies to any --once exit, but the post-design case is the sharpest because the queue just went from 1 eligible issue to N.)

Proposal

End every iteration with a one-line queue summary, e.g.:

gloop queue: 8 eligible (#2 high, #3 medium, 6 low) · 1 epic tracking · run `gloop` to continue

• After a design outcome, make the "N sub-issues queued — implementation has not started" state explicit.
• In continuous (non---once) mode, log the same summary between iterations so a tailing operator sees the loop's plan.

Acceptance

• --once exit output includes eligible-queue count and the continue hint whenever eligible issues remain.
• Design-outcome runs state explicitly that implementation hasn't started.
• Covered by a unit test on the summary formatter.

Start at the --once iteration exit and the continuous-mode iteration boundary, then locate the queue summary formatter described in the issue. Add the eligible-queue count, priority breakdown, tracking-epic count, continue hint, and explicit post-design state; cover the formatter with a unit test and verify the --once output.