Fix DNS-over-QUIC stream lifetime under cancellation

[zs311521]

@ShreyasZare This fixes a deterministic DNS-over-QUIC stream-retention path reproduced while the peer's bidirectional-stream capacity is exhausted.

On current .NET 11 preview 6 with Microsoft MsQuic 2.5.9, cancelling OpenOutboundStreamAsync while it waits for peer capacity disposes an incompletely opened QuicStream. That requests native ABORT_SEND | ABORT_RECEIVE | IMMEDIATE (0xE); under sustained traffic, repeated timed-out queries leave native streams retained until the peer or connection catches up.

The change:

• uses StreamCapacityCallback to maintain per-connection managed admission permits, so caller cancellation happens before a native stream is opened;
• owns any admitted native open through terminal completion, preserves the original caller token and absolute query deadline, and observes late work;
• serializes connection retirement and reports cleanup failures;
• makes pooled connection leases and physical eviction explicit/single-flight so expired pooled connections are actually torn down;
• keeps hot pool hits concurrent while cold construction remains single-owner.

Deterministic A/B verification against current develop:

• stock: 202 native streams at peak with two intentionally held streams;
• patched: peak stayed at the two held streams and returned to zero;
• 1,000/1,000 caller cancellations preserved the original token;
• native start/close/release/free traces balanced, with zero caller-driven 0xE;
• 50 pool churn rounds across TCP/TLS/HTTPS/QUIC left no entry behind, and concurrent cleanup joined one result/failure;
• five interleaved 60,000-query runs showed no throughput regression (36,645 stock vs 38,290 patched median QPS in the clean-branch run);
• Release build on the exact preview-6 SDK: 0 warnings, 0 errors.

This is the concrete DoQ/native-lifetime mechanism observed in the forwarder-mode investigation related to TechnitiumSoftware/DnsServer#2030. It is deliberately not presented as an explanation for every report in that broader issue.

[zs311521]

@ShreyasZare I think this is it.

We have now completed the signed production convergence around this patch, and the evidence continues to point specifically to the outbound DoQ stream ownership/cancellation race fixed here.

What is now proven:

• Deterministic exact-runtime A/B: stock peaked at 202 native streams; patched peak/baseline/final was 2/2/0. All 1,000 caller cancellations preserved token identity, native release/free balanced, and no late or unowned work remained.
• The final 200,000-query comparison stayed inside the unchanged 5% throughput gate.
• The patched primary passed classic DNS, inbound and upstream DoQ, strict wire/no-plaintext checks, semantic parity 8/8, and zero fatal/OOM events under guarded production rollback.
• Final convergence preserved every resolver process identity and required no additional DNS lifecycle action.
• The intervening failures were in our deployment verifier/control plane after the runtime had already converged: candidate bundle lookup and reconstruction of previously validated baseline evidence. They were not failures of this Library patch or of the DNS runtime, and both are now corrected and independently proven.

I am deliberately not claiming the long-term memory recurrence closed yet: the independent 24-hour and 72-hour soak windows remain pending. But the causal reproduction, exact A/B, terminal ownership proof, throughput result, and live protocol evidence all align. This is the first candidate that matches both the mechanism and the production behaviour, and I believe it is the solution.