Let a started capture outlast the reply window it began in

[RobVanProd]

Closes the open source-level blocker recorded in docs/BRIDGE_AI_HANDOFF.md:

The host's 10-second capture commitment is currently shorter than the firmware's 12-second
endpoint ceiling and can reject a valid long utterance.

The mistake

The reply window bounds how long we wait for someone to start speaking. Once they have started,
the device owns the ending — firmware's dedicated capture ceiling is 12 s, and the terminal plus the
final PCM chunks still have to reach the host after that.

But the commitment protecting an in-progress capture was:

self.capture_commit_until_ms = now + self.config.reply_window_ms

With the shipped 10 s window, a capture running anywhere near the firmware ceiling could be closed
out from under itself. The two values were never related; one just happened to be in the same units.
The comment directly above that line already stated the correct intent — "the final audio chunks can
arrive after that listening lease expires" — so the intent was right and the sizing wasn't.

The change

capture_commit_ms becomes its own configuration value, defaulting to 13.5 s, validated to sit
above the 12 s firmware ceiling and at or below the host's 14.5 s absolute capture lease.

That range is the whole point:

• above 12 s, so the longest capture firmware can take still has time to deliver its terminal;
• at or below 14.5 s, so this can never become the control that keeps an abandoned capture alive —
  the absolute lease still bounds that, and a capture that never delivers still closes on timeout.

Coverage

• a capture running to the firmware ceiling now commits (previously closed out from under itself)
• a capture that never delivers still closes on timeout, so the commitment cannot hold a session open
• the commitment no longer tracks a short reply window
• the bounds reject a value at or below the ceiling, or above the lease

python -m unittest discover -s bridge -p "test_conversation_session.py" — 19/19.
Full bridge suite: 583 tests, with only the four pre-existing numpy/opencv environment gaps
(test_rvc_directml_worker_service, test_vision_service).

Not claimed

No hardware qualification. This changes live conversation timing, and the 2026-08-11 physical
evidence in #221 was collected under the previous value. It needs a supervised run with a
deliberately long utterance — one that runs to the firmware ceiling — before promotion.

Worth noting the ambiguity honestly: in that 2026-08-11 evidence a 217-chunk (10.85 s) capture did
commit successfully, so I have not reproduced the rejection on hardware. The defect is clear in the
source and is what the handoff describes; the fix removes the coupling either way.