BASIC cannot build for riscv32, and the obvious fix breaks two targets

Measured 2026-09-07, compiler sha256 16389396da97

pascal26:5396: error: this target has no FPU and the soft-float kernel
__pxx_l2d is not linked; add `uses softfloat` to the program

i386, aarch64 and arm32 are all identical to the native run. Only riscv32 fails, and it fails with this ticket's sibling defect (bug-a-a-frontend-cannot-see-that-a-backend-calls-library-routines-it-never-mentions).

Two findings, and the second is why this is not a two-line fix

BASIC has been crossing to three targets and nothing measures it. It is the one skeleton driver with no refusal, so nothing had to be lifted to read this — the capability was already there and unrecorded, which is how a capability gets lost. It is in test-skeleton-frontends-cross-target now, for those three.

The fix that worked for the other five made BASIC worse. Placing PullTargetRuntimeUnits before PatchProgramEntryJump — the placement measured correct for Ada, Fortran, Algol, LOLCODE and Whitespace — produced invalid IR symbol reference in load_sym on aarch64 and arm32, which had been green. A net loss of two targets for a gain of none, so it was reverted and BASIC is back to exactly its previous state.

bparser differs from its five siblings in one visible way: it has its own unit mechanism, EmitProgramPrologue(False, BSourceUsesAUnit, True, jmpPatch), where the others pass a constant False. The two mechanisms plausibly interact. Plausibly is the honest word — nobody has established it, and the failing symbol was not identified.

Acceptance

riscv32 joins BASIC's row in test-skeleton-frontends-cross-target and i386, aarch64 and arm32 stay green in the same run. That second half is the whole requirement: the reverted attempt would have passed a riscv32-only check.