Pad the tgid_change closes so a talkgroup switch stops clipping the tail

The tgid_change and tgid_change_unlogged paths closed the outgoing
segment with no tail pad, on the reasoning that the new grant's
timestamp is an exact, already-known boundary. That is exact only in
control-channel time. The buffered audio lags control timestamps by
~1.5s (measured 0.84-1.62s across seven field calls), so slicing there
cut roughly the outgoing call's last 1.5s of speech - recordings ending
mid-word with ~0s trailing silence.

Both paths now pad, and the recorder's bounded tail wait blocks until
that audio has actually been captured. TAIL_WAIT_TIMEOUT_SECONDS goes
2.0 -> 4.0 so it can satisfy the 3.0s pad instead of giving up and
warning on every talkgroup switch.

The incoming call's pre-roll is served from the ring buffer, so the
delay costs it nothing. The two slices overlapping in the underlying
audio is correct: the stream genuinely contains one call's tail and
then the next call's start.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

drb-edge-node/app/internal/call_recorder.py

@@ -89,7 +89,11 @@ MAX_RECORDING_BYTES = MAX_RECORDING_SECONDS * _MP3_BYTES_PER_SECOND * 4
 # immediately therefore cuts the tail short — which costs the last word of the
 # transmission, usually the disposition or the address. Bounded so a dead capture
 # can never hang the upload path.
-TAIL_WAIT_TIMEOUT_SECONDS = 2.0
+#
+# Must exceed settings.call_tail_pad_seconds (default 3.0), otherwise a
+# tgid_change close — which pads past a timestamp that is still ~now — gives up
+# before the padded audio has been captured and warns on every talkgroup switch.
+TAIL_WAIT_TIMEOUT_SECONDS = 4.0
 TAIL_WAIT_POLL_SECONDS = 0.05
 
 # Backoff bounds for restarting a dead capture process.