Summary

Consolidate lazy dynamic-import promise memoizers behind the shared lazy-promise owner, beginning with a bounded core batch.

Problem to solve

The repository currently contains 280 production promise ??= import(...) memoizers across 169 files, alongside shared lazy runtime helpers already used by 137 files. The duplicate implementations repeat cache state and loader functions, split rejection semantics between helpers, and make future lifecycle fixes require broad manual edits.

Proposed solution

• Add the direct shared lazy-promise function API used by ordinary dynamic imports.
• Make higher-level lazy runtime selection helpers delegate to the same cache owner while preserving their existing rejection-caching behavior.
• Migrate a small coherent core cluster first, then continue package-by-package in follow-up PRs.
• Keep dynamic import boundaries intact and avoid changing plugin SDK exports in the first batch.

Alternatives considered

• One massive repository-wide rewrite: too risky for import cycles, startup behavior, and differing rejection contracts.
• Leave both shared implementations independent: retains duplicate cache ownership and makes semantics drift likely.
• Add lint enforcement before migration: premature until the canonical API and representative callers are established.

Impact

Affected: OpenClaw maintainers and developers touching lazy runtime boundaries.
Severity: Medium maintainability risk; no known user-facing bug.
Frequency: Every new or modified lazy runtime loader.
Consequence: Repeated boilerplate, inconsistent retry behavior, and higher risk during runtime-boundary refactors.

Evidence/examples

Current main search counts:

280 manual `??= import(...)` occurrences in production TypeScript
169 production files containing those manual memoizers
137 production files already using shared lazy helper APIs

The first PR will include focused helper tests, build/import-boundary proof, duplicate search proof, and production LOC reduction.