fix: handle unmatched 487 response on delayed call cancellation

[shokoban]

Summary

• Delayed INVITE cancellation (around 32 seconds after creation) could cause a cancelled transaction to be immediately expired.
• As a result, the final 487 Request Terminated could no longer be matched to the transaction and was surfaced as a generic SIPTransportResponseReceived event.

This PR updates cancellation lifecycle handling in SIP transactions:

• Add CancelledAt property to SIPTransaction to track the cancellation timestamp.
• Change SIPTransactionEngine to use CancelledAt (instead of Created) when expiring transactions in the Cancelled state.

Why this approach:

• Expiration for cancelled transactions should be based on when cancellation happened, not when the transaction was originally created.
• This keeps the transaction available to correctly consume the final 487 and complete cleanup gracefully.

Test plan

• dotnet build SIPSorcery.slnf -c Release
• dotnet test test/unit/SIPSorcery.UnitTests.csproj -c Release -f net8.0
• dotnet test test/unit/SIPSorcery.UnitTests.csproj -c Release --framework net10.0

Notes

• Behavior change: Cancelled INVITE transactions are no longer prematurely garbage-collected solely due to age since creation.

References

• Discussions: Different events triggered when cancelling an INVITE before vs. after 32 seconds (T6) #1534

Assisted-by: GPT-5.3-Codex

[shokoban]

Please accept my apologies for the delayed response. I have made the changes based on your feedback. Could you please review it?