fix(dialog): end the INVITE of an aborted do_invite_async task

[tgeorge06]

Fixes #204.

Problem

DialogLayer::do_invite_async drives the INVITE in a spawned task (src/dialog/invitation.rs:786-787 at current main, 6fd9414) that holds no drop guard. Aborting that task before the final response drops the INVITE client transaction: no CANCEL, a 2xx is neither ACKed nor ended with a BYE, the dialog stays in Calling or Early, and its early entry stays in the dialog layer. do_invite has handled the same drop correctly since #171.

Expected

The same as a dropped do_invite future. RFC 3261 §9.1:

If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request.

and a 2xx that the CANCEL did not prevent is ACKed and ended with a BYE (§9.1, §15).

Fix

The spawned task now holds the same DialogGuardForUnconfirmed that do_invite uses (invitation.rs:186-339), set up exactly as in do_invite: the guard owns the transaction while process_invite runs, is disarmed (dialog = None) when it returns, and the transaction is taken back for the Accepted-state drainer. On abort the guard's existing Drop runs: CANCEL at once in Trying/Early, on the first provisional in Calling, ACK + BYE for a 2xx, layer entry removed. +19 / -2 lines in src/dialog/invitation.rs; the rest of the +81 / -2 is tests.

Unchanged on purpose:

• A task that runs to completion behaves as before: the early key is removed before the guard drops (which then finds no entry and returns), and a 2xx registered under its confirmed id is neither removed nor hung up.
• Dropping the JoinHandle without abort() still detaches the task, which keeps running. On platform-embassy there is no abort(), so nothing changes there.
• Transaction::receive is not cancel-safe: an abort that lands while receive() is processing a 2xx can still lose it, exactly as for a dropped do_invite future today. That is a separate, shared issue.

Contract / coverage

do_invite_async task aborted before the final response:

aborted in	peer then sends	before	after
Calling	180	nothing	CANCEL; 487 ACKed
Calling	200	nothing (no ACK, no BYE)	ACK + BYE
Early	(none needed)	nothing	CANCEL at once; 487 ACKed
any		early entry left in the layer	removed

Tests

src/dialog/tests/test_cancel_2xx_race.rs, against a raw UDP peer: test_aborted_invite_task_in_calling_is_cancelled_after_the_180, test_aborted_invite_task_in_calling_2xx_is_acked_and_byed, test_aborted_invite_task_in_early_is_cancelled. Each also asserts the layer is empty afterwards. On main (6fd9414) all three fail: timeout waiting for CANCEL (both CANCEL cases) and timeout waiting for ACK (the 2xx case).

Checks

• cargo test --features bench: 423 lib tests passed, 0 failed (420 on main plus the 3 new ones), and 65 doc tests passed. Plain cargo test passes too.
• cargo check --no-default-features --features platform-embassy: no warnings, as on main.
• cargo clippy --features bench --all-targets: the same output as on main, none in the changed code. (On main it stops at a clippy::never_loop error in src/dialog/tests/test_refer_notify.rs:98, unrelated to this PR; with -A clippy::never_loop the warnings are the same as on main.)
• cargo fmt --check: clean.
• Independent of InviteDialog::cancel() returns Ok(()) and does nothing: UAC before the first provisional, and any UAS dialog #197's PR and of fix(transaction): answer a CANCEL after a final response with its own 200 #199; merges cleanly with both.