Fix loader lifecycle and promise adapter selection

[simPod]

Summary

• Track loader instances and promise adapters with weak references.
• Keep loaders strongly referenced only while they have queued work.
• Resolve each promise with its producing adapter, including mixed-adapter use.
• Settle adapter callbacks created by dispatch before no-argument await() returns.

Lifecycle Decision

DataLoader::await() must dispatch queued loaders, settle the dispatched work,
and use the adapter that owns the supplied promise. A strong global registry
retained every loader and its cache, and selecting the first loader could use
the wrong adapter in mixed-adapter applications.

Use weak references for loader instances and promise ownership. Retain a loader
strongly only while it has queued work, and remove it when dispatch starts. For
promises without recorded ownership, select a live adapter that recognizes the
promise before using a compatibility fallback. Drain the owning adapter after
dispatch so no-argument await() does not return before callbacks settle. A
loader destructor cancels only its own queued promises.

Idle and dispatched loaders can be collected, inline temporary loaders remain
alive until dispatch, and queued work remains retained until the application
dispatches or cancels it.

[simPod]

Blackfire Performance Profile

The CLI workload creates and immediately awaits 2,000 temporary DataLoader
instances with the Webonyx synchronous promise adapter.

Revision	Wall time, median	CPU time, median	Memory
Previous dataloader-php master 0ee3ee2	2.11 s	2.10 s	4.17 MB
Changed loader registry	114 ms	90.9 ms	1.20 MB

This is an 18.5x wall-time improvement, 23.1x lower CPU time, and 71.2% lower
memory use. The medians use three alternating Blackfire profiles per revision.

The profile targets the loader lifecycle path changed in this PR. Xdebug and
PCOV were loaded for both revisions, so the relative difference is the useful
result.