docs(architecture): define the iDevice runtime contract (#2511) - #2513

Closes #2511

Thanks @ignaciogros for opening this and for spotting the pattern behind #2170 and #2510.

Problem

iDevice runtime scripts, the two hosts that drive them (exe_export.js on exported pages, IdeviceNode / IdevicesEngine in the editor) and the shared libraries have no written contract. Every enhancement and every teardown gets wired again case by case: #2170 (effects), #2510 (lightbox), #2271 / #2293 (edition teardown), and #2434 (the editor reloads the whole page after a remote edit because runtimes act page-wide).

What this PR adds (documentation only)

Change directory doc/architecture/changes/2511-idevice-runtime-contract/:

• proposal.md: motivation, problem, scope, goals and non-goals.
• spec.md: the contract, as numbered requirements (R2–R8), scenarios and acceptance criteria:
  • instance identity by component id;
  • render lifecycle: view → mount → behaviour → init (may return a Promise) → enhance → rendered, with an error boundary and a timeout per instance;
  • self-updates through $exe.ideviceRuntime.rendered(node, 'update');
  • one enhancement step whose entries take a context and are idempotent;
  • ready signal: the exe-idevice-rendered event per instance and exe-idevices-rendered per page, replacing the 200 ms delays before print and search highlighting;
  • teardown through $exe.ideviceRuntime.destroy(node) and an optional destroyRuntime hook;
  • compatibility with legacy runtimes.
• design.md: how it is built. A new host-neutral classic script, exe_idevice_runtime.js, is loaded by both hosts; it is needed because exe_export.js is not loaded in the workarea. The design also covers the changes to each host, migration, security, accessibility, performance and testing.
• research.md: a survey of all 53 base iDevices and the shared enhancements, with file and line evidence. It covers which runtimes act page-wide, which work asynchronously after init, which resources leak, and which enhancements are not idempotent.
• tasks.md: a phased adoption plan, one PR per step. The runtime core and the enhancement list come first, then the editor host, then the jsonOnlyIdevices one by one, then the gamification helpers. The HTML-type games get a separate follow-up issue.

ADRs, all Proposed:

• ADR-2511-01: run every iDevice instance through one render lifecycle that ends in a DOM event.
• ADR-2511-02: share one enhancement step between the editor and exported pages. It builds on ADR-2510-01 from Export: bind lightbox links in iDevices rendered after page init. #2512.
• ADR-2511-03: own exported iDevice resources with a lifecycle shared with editions. It is the runtime counterpart of ADR-2293-01.

Decisions to review

1. Ready signal: a DOM CustomEvent (exe-idevice-rendered, with reason and status in detail). init may return a Promise, which the host waits for under a timeout. Sync iDevices need no change.
2. Enhancement step: $exe.ideviceRuntime.enhance(context) in a file both hosts load. afterIdeviceRendered() stays as a wrapper around it, and the two copies of loadLegacyExeFunctionalitiesExport() collapse into it.
3. Teardown: a ResourceLifecycle with the same API as EditionLifecycle, one per instance, plus an optional destroyRuntime(ideviceId, node) hook. The name avoids destroy, which the 3D viewer runtime and SimpleLightbox already use. EditionLifecycle will delegate to it so the two lifecycles cannot drift apart.

Left out

• No code changes. Implementation follows tasks.md, starting after this is accepted and Export: bind lightbox links in iDevices rendered after page init. #2512 is merged.
• ADR-2510-01 not yet listed in the metadata: Export: bind lightbox links in iDevices rendered after page init. #2512 is merged, and the proposal and ADR-2511-02 now link it.
• Converting the HTML-type games to per-node initialization (tasks step 7, separate issue).
• Whether jsonOnlyIdevices should move into each iDevice's config.xml (left as an open item in tasks).
• The idevice skill gets its "Runtime lifecycle" section when step 1 lands, so it never describes an API that does not exist yet.

Validation

• make architecture-check: Architecture records OK — 37 records, 7 changes.
• All relative links in the new files resolve. doc/architecture/adr/ and changes/ are excluded from MkDocs navigation (mkdocs.yml).
• No screenshots: documentation only.