[triage:service-live-log-buffering] Active service log stream remains empty during live route handling

## Summary

The service emits info-level route evidence, but its active file log stream can remain zero bytes until teardown. Live log readers and Ironbank therefore cannot observe events that were successfully emitted while the service is still running.

## Current-main evidence

`tests/ironbank/test_mcp_protocol_ledger.py::test_observed_remote_mcp_protocol_pays_full_ledger_blackbox` completed its real-VM MCP, SQLite, UDS, gateway, and security assertions, then failed because `read_log_stream(service.tmp_dir / "service.log")` returned empty. The preserved artifact had zero-byte `service.log` and `service..log` files.

The exercised handler contains an info event at `crates/capsem-service/src/main.rs` (`security_latest`), and the fixture runs with `RUST_LOG=debug`, so filtering is not the cause.

## Impact

- Live `/service-logs` and test readers can miss recently emitted diagnostics.
- Release proof that requires structured route evidence fails despite successful product behavior.
- Incident triage may see an empty service log until process shutdown flushes buffered output.

## Scope

Diagnose buffering and flush ownership in `capsem_core::telemetry` and add a deterministic RED/GREEN regression. Keep this separate from logger/MCP protocol accounting work.

Run tests/ironbank/test_mcp_protocol_ledger.py::test_observed_remote_mcp_protocol_pays_full_ledger_blackbox and inspect capsem_core::telemetry, along with the handler in crates/capsem-service/src/main.rs. Trace buffering and flush ownership while the service is running. Done means a deterministic RED/GREEN regression confirms service.log contains emitted route evidence before teardown.

Written by the indexing model from the issue text.