[Injection] Tie the Revit connection to the test host process

[Nice3point]

Holds one Revit connection for the life of the test host process.

What changed

• RevitApiTest opens the connection on the first session that executes a test, and a later session in the same process keeps it. Revit activates once per process, and the second session used to fail the whole run.
• RevitConnectionLifetime, an ITestHostApplicationLifetime, releases the connection on the Revit thread after the last session of the process. The package registers it through the TestingPlatformBuilderHook item of its build props; a consuming project needs no change, and a project with its own entry point calls AddRevit.
• RevitApiTest.RevitSessionCleanup is gone. It released the connection after every session.
• The changelog and the instruction file carry the process-wide connection.

Where to look

• The connection opens from the session hook and from nowhere earlier. ITestHostApplicationLifetime.BeforeRunAsync was the alternative for a symmetric pair, and it runs for a discovery request too, which would start Revit whenever an IDE lists the tests. The cost of the session hook is that the pair is split across two mechanisms.
• The eject sits in AfterRunAsync and carries no timeout. A run that leaves Revit connected never terminates, and a hung eject would hang the host; a timeout would instead exit and leak. The current behaviour matches what the package already did.
• build/Nice3point.TUnit.Revit.props is packed into both build and buildTransitive. Packing into build alone was the alternative, and it would drop the registration for a project that receives the package through a shared test library, which fails as a host that never exits.

How verified

• Build: Debug.R21 (net48), Debug.R26, Debug.R27 and Release.R27 — zero warnings, zero errors. Debug.R24 could not restore Nice3point.Revit.Injector from the feed here (401), and Debug.R21 covers the same target framework.
• Full suite, Debug.R27 against Revit 2027: 62 tests, zero failures, 4 skipped. The host exits about a second after the last test.
• Two sessions in one process, through the reproduction client from the issue: run 1 finished in 4s : passed=1, run 2 finished in 0s : passed=1, server exit code 0. On develop the second run reports [Setup Failure] BeforeTestSession hook failed: Attempted to write protected memory.
• Discovery alone, --list-tests: 61 tests found in 115 ms and the process exits in 1.5 s, so Revit never starts and the lifetime releases nothing.
• The eject is load-bearing: with the release removed the process never terminated and was killed at 300 s, against about a second with it.
• Not covered: the Release package path, and a Visual Studio Test Explorer session driven by hand. The reproduction client sends what Test Explorer sends.

Open questions

• The parallel limit is not delivered here. RevitThreadExecutor declares an IParallelLimit of 1, and TUnit installs an executor without forwarding ITestRegisteredEventReceiver to it, so the limit never reaches the scheduler and Revit tests interleave at every await. The fix is fix: preserve executor registration, limiter precedence, and timeout classification thomhurst/TUnit#6768, and the limit starts applying with the TUnit version that carries it. Measured on this branch: a test class that inherits RevitApiTest reports Parallelism.Limiter as null, and a suite whose tests share state across await needs --maximum-parallel-tests 1 until the update.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.