Document untrack behavior with uninitialized async reads (NotReady propagation)

From solidjs/solid#3007 (reported by @mizulu).

The untrack reference page (https://v2.solidjs.com/reference/solid-js/reactivity/untrack) should document how untrack interacts with async reads in 2.0:

• untrack stops dependency tracking — reads inside it do not subscribe the surrounding computation.
• It does not opt out of async settlement. Reading an async source that is not yet ready inside untrack still throws NotReadyError, which propagates to the owning computation: the owner suspends (participates in Loading boundaries) and re-runs once the source first resolves.

In other words, untrack(() => getColor()) where getColor is a pending async memo will still cause the owner to re-run when getColor first settles — the read is untracked, but the not-ready suspension is part of async graph resolution, not tracking.

The page should spell out this distinction (tracking vs. settlement) and show the pattern for a genuinely non-suspending read of a possibly-pending source (e.g. checking readiness with isPending/latest as appropriate) so users aren't surprised that untrack alone doesn't provide a fallback-value escape hatch. A fallback-value overload for untrack was considered in solidjs/solid#3007 and rejected — the docs are the fix.

Bắt đầu với trang tham chiếu untrack được liên kết trong issue và xem lại hành vi đọc bất đồng bộ được mô tả ở đó cùng với ngữ cảnh của solidjs/solid#3007. Cập nhật trang để phân biệt việc theo dõi dependency với việc hoàn tất NotReady, giải thích việc owner bị suspend và chạy lại, đồng thời hiển thị một kiểm tra trạng thái sẵn sàng thực sự không suspend bằng isPending/latest.