test(archtest): the recursion pin's load can trip a go/types data race #855

Problem

loweringCallGraph (internal/archtest/recursion_test.go) type-checks the four lowering packages in one packages.Load call:

• compilers/openapi
• compilers/openapi/internal/auth
• compilers/openapi/internal/operation
• compilers/openapi/internal/schema

go/packages type-checks every package whose imports are done at the same time, one checker per package. auth and schema import neither each other nor the other two, so their checkers can run concurrently.

Go 1.27.2's go/types has a data race between concurrent checkers that share an imported package (golang/go#81122). Checker.isComplete reads Named.fromRHS with no lock, while another checker's Named.unpack writes it as it expands a generic instance from that package. The fix (golang/go#81871) is not in any release. Under -race, which make coverage and CI use, the race fails every test running in the binary at that moment.

#837's first version loaded ir and the whole compilers/openapi tree in one call this way. Its compilers/openapi tests failed 1 run in 15 under make coverage's flags, with Named.unpack against Checker.isComplete inside packages.(*loader).loadPackage. archtest's load has the same shape with fewer independent roots. 40 isolated runs of the recursion pin on main at a2530c3 did not trip it, so it is rare, not impossible.

Expected

No packages.Load call in the test suite type-checks two packages at once. Either would do:

• load each lowering package in a call of its own, as test: read package declarations type-checked, not parsed #837's decls.LoadEach does, and compare cross-package objects through what each package imports;
• give the call roots that form a chain, so each waits for the one before.

Acceptance

• The recursion pin's load never has two roots that are independent of each other.
• The pin still reddens on a planted cycle within a package, and still records the calls from one lowering package into another.