pua_dialoginfo: fix early state lifetime and clean up dangling early branches

[NormB]

Fixes #3802, as requested in #3802 (comment).

This is the patch from the Feb 13 comment, tested by @andrewyager in pre-prod/prod against 3.4, rebased onto current master with the following adjustments:

• The failure-handler loop now iterates only the last set of active branches (t->first_branch .. t->nr_of_outgoings) instead of all MAX_BRANCHES, per @bogdan-iancu's review comment.
• Adapted to the new branch bitmask API from f0223cc (BRANCH_BM_TST_IDX/BRANCH_BM_SET_IDX instead of raw long long shifts) and to TM_BRANCH().
• The handler now also sets bitmask_failed for each branch it terminates, so a late-arriving negative reply on that branch cannot publish a duplicate "terminated".
• The handler honors the DLG_PUB_A/DLG_PUB_B publishing flags, consistent with the rest of the callback.
• No locking in the failure path: TMCB_ON_FAILURE already runs under the transaction's reply lock (via t_should_relay_response() -> run_failure_handlers()), so the bitmask test/set is safe and re-taking t->reply_mutex would deadlock.

Summary of the fix

1. On 1xx replies, use DEFAULT_CREATED_LIFETIME for the published state lifetime instead of fr_timer.time_out - get_ticks() — the fr_timer is updated only after TMCB_RESPONSE_IN runs, so a provisional reply arriving close to the timer expiration produced a near-zero lifetime and orphaned presence records.
2. Hook on TMCB_ON_FAILURE and publish "terminated" for any branch that entered "early" state but never received a final negative reply, so the longer lifetime cannot leave a dangling "early" state when the UAS goes silent after ringing.

Re-validation on current master

Re-ran the scenarios from the issue against this rebased patch (master @ 4ddb8f0, loopback, fr_timeout=10, fr_inv_timeout=15):

• Late 180 (8s delay): early state published with expires=3600 (previously 7s remainder); 200 OK then publishes confirmed with the dialog lifetime — original bug fixed.
• Silent UAS (180 then nothing): on fr_inv_timeout, "terminated" with expires=0 is published for both directions before the failure route runs, and pua deletes the record from its hash table — no dangling early state.
• Successful call: no spurious "terminated" from the failure handler.

[bogdan-iancu]

Thank you @NormB

[andrewyager]

Thank you!