Treat temporary SIP dispatch IDs as transactional route identity

General lesson: An isolated PSTN canary that creates a temporary SIP dispatch rule must treat the provider-issued rule ID as part of the end-to-end route identity. Do not reuse or fake the normal rule ID: the real SIP participant reports the temporary ID, and durable ingress/session validation should compare that value exactly. A safe canary therefore needs a narrowly scoped, compare-and-swap route transition for one dedicated non-customer DID, followed by guaranteed restoration.

Applicability and limits: This applies when dispatch rules produce provider-assigned IDs that are persisted and revalidated downstream. Use a rule scoped to both the approved caller and called number, reject unexpected overlapping rules, retain the ordinary wildcard route for everyone else, and record a private crash-recovery checkpoint before mutation. It does not validate webhook delivery if the harness observes the SIP participant directly; webhook qualification remains a separate gate.