fix(kap-server): make boot and telemetry shutdown lifecycle complete

Context

PR #2230 added a deliberately local, 3-second best-effort telemetry close path to kap-server. The review also exposed broader server lifecycle gaps that were kept out of that PR.

Problem

• The server must quiesce asynchronous engine telemetry producers before the final telemetry flush; otherwise events can be emitted after the flush boundary.
• If startServer fails after partially initializing scopes, routes, or telemetry, boot needs one complete rollback path rather than ad hoc cleanup at individual call sites.

These are server lifecycle invariants, not part of wiring a new telemetry appender.

Scope

• Define and enforce shutdown ordering: stop intake, quiesce producers, perform bounded telemetry shutdown, then dispose remaining scopes/resources.
• Preserve the invariant that telemetry failure never blocks core/instance cleanup.
• Make partially completed startServer initialization unwind every acquired resource exactly once.
• Avoid changing public CLI shutdown policy in this issue.

Acceptance criteria

• No telemetry event can be produced after the final flush boundary.
• Cleanup continues when telemetry flush rejects or reaches its deadline.
• Failure injection at each meaningful boot stage leaves no live server, timer, appender, or scope.
• Normal close and partial-boot rollback are idempotent and covered by tests.

Follow-up to #2230.

Start at startServer and the lifecycle path discussed in PR #2230. Trace boot and close handling for scopes, routes, telemetry, timers, and intake; use failure injection at each meaningful boot stage and verify idempotent normal close and rollback, continued cleanup after telemetry failure, and no event after the final flush boundary.