fix: Do not relay a transport the bridge did not restart

[bgrozev]

A transport with no ice-generation in a colibri2 response is not the answer to an ICE restart. The bridge sends it when it did not restart and described the Agent it already has, which it does when its own transport has not connected yet: there is nothing to preserve, and nothing for the participant to do.

ColibriV2SessionManager.endpointIceRestarted treated it as a relayed restart:

• lastRelayedIceGeneration was set to GENERATION_UNSPECIFIED, resetting the high-water mark. The staleness guard then let a generation that had already been relayed through a second time.
• ice_restarts_relayed counted a restart that never happened.
• The participant was sent a transport-info it has nothing to do with. lib-jitsi-meet does not take the ICE restart path for an untagged transport, so it was ignored -- noise rather than a fault.

Now an absent generation is handled for what it is: log it, count it in the new ice_restarts_not_needed metric, relay nothing. The staleness check no longer needs to exclude untagged transports because they never reach it.

The existing test for untagged transports asserted the old behaviour and is replaced by two: the untagged transport is not relayed, and it does not lose the generation of the last one that was.

Independent of the bridge side, which is where these transports come from: jitsi/jitsi-videobridge#2438. Raised in review there: jitsi/jitsi-videobridge#2438 (comment)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 51.57%. Comparing base (d4d1458) to head (bb364c8).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1302      +/-   ##
==========================================
+ Coverage   51.53%   51.57%   +0.03%     
==========================================
  Files         132      132              
  Lines        8419     8425       +6     
  Branches     1285     1285              
==========================================
+ Hits         4339     4345       +6     
  Misses       3471     3471              
  Partials      609      609              

Files with missing lines	Coverage Δ
...tlin/org/jitsi/jicofo/metrics/IceRestartMetrics.kt	92.30% <100.00%> (+2.30%)	⬆️
...org/jitsi/jicofo/bridge/colibri/Colibri2Session.kt	69.57% <ø> (ø)
...i/jicofo/bridge/colibri/ColibriV2SessionManager.kt	59.34% <100.00%> (+0.26%)	⬆️

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d4d1458...bb364c8. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[JonathanLennox]

Note: this comment was generated by AI (Claude Code), following on from the review comment on jitsi/jitsi-videobridge#2438 that prompted this PR. Please treat it as something to check rather than as established fact.

The change reads correctly to me, and ColibriV2SessionManagerTest passes locally (28 tests). Returning early before lastRelayedIceGeneration = generation is what preserves the high-water mark, and dropping the generation != GENERATION_UNSPECIFIED clause from the staleness check afterwards is right, since untagged transports can no longer reach it. The replacement test is well aimed at exactly the regression the old code had.

One thing left over, in a file this PR does not touch — Colibri2Session.kt:219-220:

// The bridge declined the restart (disabled in its configuration, transport not established yet,
// or shutting down). It says so by omitting the transport rather than by returning an error.

Both halves of that list are now out of date, in opposite directions:

• "transport not established yet" no longer omits the transport. That is precisely the case where the bridge answers with the Agent it already has, so it now arrives as an untagged transport and is handled by the new branch this PR adds — not by endpointIceRestartFailed.
• The bridge has since grown another way to omit the transport that is not listed: it answers UNAVAILABLE when it fails to create the new Agent (jitsi/jitsi-videobridge@77dd7ba7a). That one is a resource problem on the bridge rather than a configuration choice, and it is the case where escalating to a re-invite matters most.

Since this PR is specifically about pinning down which shape of response means what, that comment seems like the natural thing to correct alongside it — it is currently the only place in jicofo that documents the mapping, and it now points the reader at the wrong branch for the not-established case.