Fix duplicate Intercom call-location notes

[EdgeClaws]

Summary

• write a stable [edge-call-location call_id=…] receipt into each internal call-location note
• on Intercom redelivery, retrieve the conversation and skip note creation when the exact call receipt already exists
• reconcile an ambiguous note-write response by reading the durable receipt before deciding whether Intercom should retry
• run the note and contact-attribute writes concurrently, use short call-specific HTTP timeouts, and reuse the existing pinned admin ID instead of calling /me on every cold invocation
• return a retryable error when a write or receipt proof fails; suppress the note when the stable call ID is missing or invalid

Why

Intercom waits five seconds for a webhook response and retries once after one minute. The existing cold path could make three sequential Intercom requests before returning 200, then unconditionally created another note on the retry because it ignored both the notification ID and call ID.

Documentation: https://developers.intercom.com/docs/webhooks/webhook-notifications

Verification

• Python 3.12.14 (the DigitalOcean runtime)
• 174 passed
• Python compile check
• project.yml parse + manifest regression
• git diff --check
• gitleaks: no findings

The regression matrix includes the exact first-delivery → one-minute-retry sequence, ambiguous write committed with response loss, attribute failure followed by retry, missing receipt, malformed receipt readback, different call IDs, invalid IDs, and proof that the two first-delivery writes execute in parallel.

Deployment boundary

• no Intercom or production mutation has occurred
• deploy only intercom/webhook into the isolated staging namespace first
• do not merge until staging proves the receipt survives Intercom note canonicalization and replaying the same signed call event produces exactly one note
• intercom-article-drafts/upload and every other deployed action remain outside this deploy scope

This fixes Intercom's documented delayed redelivery and ambiguous-write paths without adding a datastore. It does not claim atomic exactly-once behavior for two genuinely simultaneous first-attempt deliveries landing in separate function containers; that would require an external conditional-write/lock service.