Feat: AICPU dispatcher bootstrap + cached AICore rtRegisterAllKernel handle (re-apply #537)

[ChaoWao]

Summary

Re-applies #537 (reverted in #867 because the prepared_callable
TestPreparedCallableHbgA5 suite OOM'd at first AICore launch on a5/onboard)
on top of a fix for the underlying leak that #537 exposed.

The bug that caused #867

launch_aicore_kernel was calling rtRegisterAllKernel on every run, binding
the returned bin_handle to a stack-local that vanished at function exit.
CANN has no public rtUnregisterAllKernel, so each register pinned another
device-side copy of the AICore ELF (~365 KB on a5/hbg) — the kernel binary
leaked once per run(). The leak was pre-#537 too, but masked by lower
steady-state HBM use. #537 made rtsBinaryLoadFromFile keep the AICPU SO
loaded for the DeviceRunner lifetime — enough extra resident HBM that the
very first AICore launch on a5/hbg tipped into 207001
(ACL_ERROR_RT_MEMORY_ALLOCATION), and the broken driver state cascaded into
507899 at the next rtStreamCreate.

a2a3 stayed lucky because its AICore ELF is ~5x smaller (78 KB vs 365 KB on
a5 — MIX-mode binary + heavier debug info on a5; .text alone is 10.8 KB vs
2.7 KB).

Fix

Cache the AICore rtRegisterAllKernel handle in aicore_bin_handle_ and
register lazily on the first launch_aicore_kernel. Reset to nullptr in
finalize(); CANN releases the device-side state implicitly when the device
context tears down. Applied symmetrically to a2a3 and a5 — a2a3 had the same
latent leak.

What's the same as #537

Everything else: dispatcher SO build (libsimpler_aicpu_dispatcher.so
per-arch), LoadAicpuOp bootstrap + per-task rtsLaunchCpuKernel,
content-fingerprinted simpler_inner_<fp>.so preinstall write, process-level
fingerprint cache, RuntimeBinaries.dispatcher_path threading.

Comments were also audited to drop "Mode A / Mode B" wording (development
shorthand that wasn't useful for readers) and to correct the "load-bearing"
provenance note on AicpuSoInfo (the previous comment attributed 207001 /
507899 to dropping aicpu_so_bin/len; the real cause was the AICore handle
leak — but the H2D allocation does still appear independently load-bearing,
so it stays).

Testing

• tests/st/a5/host_build_graph: 7 passed (incl. all 5
  TestPreparedCallableHbgA5 cases that originally failed)
• tests/st/a5/tensormap_and_ringbuffer + examples: 22 passed (2 pre-existing
  g++-15 sim-only failures unrelated to this change)
• CI st-onboard-a5 (this PR)
• CI st-onboard-a2a3 (this PR)

Fixes #356 (closes the gap that caused #867).

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!