cdr: store Cdr events, aggregate calls, fixtures from real calls

services/cdr.ts stores every AMI Cdr event in cdr and, 5 s after a
call's last event, builds its calls row (direction, status, from, to,
DID, answered by, talk time) and call_extensions (caller, rang,
answered) per 04 §5.4; linkedids without a calls row are caught up on
AMI connect. Aggregation is idempotent.

test/asterisk/cdr-record.ts records 8 scenarios with our config, the
fake voip.ms (now shared in provider.ts) and baresip phones; each has a
fixture and a test with the expected calls row. Queue abandon and park
come with M8.

Found while recording: Asterisk 24's Cdr event has no LinkedID unless
cdr_manager maps it, its times carry no zone (now usegmtime), and the
mappings read CDR variables, so the dialplan sets CDR(SP_DID) and
CDR(SP_DIRECTION) next to the channel variables. The Asterisk image
needs a rebuild for the cdr_manager.conf change.

Task: M7-T1

docs/spec/01-infrastructure.md

@@ -502,12 +502,16 @@ endbeforehexten = yes
 ; cdr_manager.conf
 [general]
 enabled = yes
+usegmtime = yes            ; times in UTC: the api parses them without guessing a time zone
 [mappings]
+linkedid => LinkedID       ; groups every leg of one call; not in the event by default
 SP_DID => sp_did
 SP_DIRECTION => sp_direction
 SP_REC => sp_recording
 ```
 The api turns `Cdr` AMI events into rows in `cdr` (see `04-backend-api.md` §5.4).
+Without the `linkedid` mapping, Asterisk 24's `Cdr` event has `UniqueID` but no `LinkedID`, and
+its times have no zone (checked on 24.0.0-rc2, M7-T1).
 
 ## 4. Networking and NAT