feat(miner-manage): loop-closure summary builder (pre-reentry, read-only)

[JSONbored]

No "loop-closure"/"cycle summary"/re-entry concept exists anywhere in packages/gittensory-miner/ today (confirmed by search) — this is genuinely new. It's a pure, read-only aggregator, in the spirit of manage-status.js's collectManageStatus: read across the local-state primitives already in the package (or landing alongside this issue via the sibling schema/writer issues) and summarize what happened in a completed discover→plan→prepare→manage cycle before the miner loop considers re-entering (idle → discovering again per run-state.js's RUN_STATES, run-state.js:6).

The one real design gap to flag: there's currently no "cycle boundary" marker in the event vocabulary. event-ledger.js's readEvents({ since }) (event-ledger.js:167-184) already supports "everything after seq N," which is the right primitive to bound "this cycle's" events — but nothing today stamps a cycle_started/idle_reentry-style event to mark where a cycle began, so the boundary needs to come from somewhere. Simplest option: take the last cycle's ending seq as an explicit argument to the summary builder (caller-supplied boundary) rather than inventing a new persisted "current cycle" pointer — flagged here so the implementer picks deliberately instead of guessing.

Deliverables

• packages/gittensory-miner/lib/loop-closure.js exporting a pure buildLoopClosureSummary(sources, options) — read-only, no GitHub calls, no local-store writes
• Inputs: run-state.js's current/prior state, event-ledger.js events since an explicit sinceSeq (or equivalent caller-supplied boundary — do not invent a new persisted cycle-boundary marker as part of this issue), portfolio-queue.js's current queue snapshot, and collectManageStatus's managed-PR rows (manage-status.js:59)
• Output: a small structured summary (e.g., issues discovered, plans built, PRs prepared/opened, outcomes recorded this cycle, queue state at cycle end) suitable for both --json and a human-readable render, mirroring manage-status.js's renderManageStatusTable split between data-collection and rendering
• Explicitly out of scope: deciding whether to re-enter the loop, or performing the re-entry itself (run-state.js's setRunState) — this issue only builds the summary that a future caller reads before making that call
• Unit tests covering an empty cycle (nothing happened), a cycle with a mix of event types, and the sinceSeq boundary actually excluding prior-cycle events

References

• packages/gittensory-miner/lib/event-ledger.js:167-184 (readEvents({ since }) — the cursor primitive to bound a cycle's events)
• packages/gittensory-miner/lib/run-state.js:6,100-106 (RUN_STATES, getRunState/setRunState — the idle/re-entry boundary this precedes)
• packages/gittensory-miner/lib/manage-status.js:59-107 (collectManageStatus — the aggregation style to mirror; also a direct data source)
• packages/gittensory-miner/lib/portfolio-queue.js:184-186 (listQueue — queue-state-at-cycle-end input)
• Sibling issues: local pr_outcome writer and unified local-schema docs (this builder should read whatever those land, not duplicate their storage)

[linear-code]

JSO-3269