Bound integration dispatcher flush-on-close latency

[kjgbot]

Follow-up from pear#82 Track B / PR #106 review. PR #106 was restored to the reviewer-approved head ead8dfd and keeps the current dispose-and-drop close semantics for this merge lane. This issue tracks the deliberate bounded flush-on-close design that was rejected as an unowned bot delta but considered the better long-term design when implemented intentionally.

Context:

• IntegrationEventBridge.close() is awaited by reconcile() on integration settings/signature changes, not just app quit.
• An unbounded flush can turn a settings tweak into a long close/reconcile hang because delivery may call sendMessageAndWaitForDelivery with a 15s timeout per recipient/send.
• Queue admission already bounds a close flush to roughly 50 queued individual events plus up to 10 summary groups, so the remaining risk is close wall-time and broker-send pacing, not 1,000 raw sends.

Acceptance criteria:

• Bound close() wall time, not just iteration count. Target about a 2s total teardown flush budget.
• Do not let an in-flight sendMessageAndWaitForDelivery block close past the budget. Either use fire-and-forget sendMessage during teardown or race/abandon delivery work at the budget boundary.
• At budget expiry, count leftover queued events and summary groups as eventsDropped.
• Emit one aggregated summary log line for the abandoned close-flush work.
• Add a slow-broker regression proving close() returns within the budget, with margin, while a send is stuck.
• Keep steady-state dispatcher drain semantics unchanged outside teardown: rate limit, scheduling, counters, coalescing, and summary behavior should remain byte-equivalent in intent.
• Keep the existing bridge/full suites green.

Track E ledger reference:
Even with bounded close flushing, the residual teardown burst is still up to about 61 sequential sends. Track E remains responsible for per-project broker sendMessage pacing/rate limiting on top of the Track B dispatcher baseline.