docs: document observerMap accessor idempotency assumptions in fast-html

[janechu]

🙋 Feature Request

Document the intended idempotency behavior of observerMap-generated accessors in fast-html, especially that observerMap item objects are expected to be plain objects and that a pre-existing accessor with the same property name is treated as already installed.

This is a follow-up documentation/code-comment issue for #7559.

🤔 Expected Behavior

The implementation should make it clear to future maintainers that defineObservableProperty intentionally checks Observable.getAccessors(targetObject).some(a => a.name === key) and skips defining a new accessor when one already exists.

It should also be clear that this is appropriate for the documented plain-object observerMap item shapes, but class-instance item support would require a more explicit ownership marker.

😯 Current Behavior

The behavior exists in code but is not documented near the helper. Because Observable.getAccessors includes inherited accessors, a class instance with a base-class accessor for the same key could skip observerMap's schema-specific accessor path. That is likely acceptable for the documented plain-object case, but it is a latent trap for future maintainers.

💁 Possible Solution

Add a short comment near defineObservableProperty stating:

• observerMap item objects are expected to be plain objects;
• the idempotency check intentionally treats any pre-existing accessor with the matching name as already installed;
• if class-instance item support becomes a requirement, observerMap-created accessors should use an explicit internal marker/symbol rather than trying to infer ownership from function closures.

No behavior change is required unless class-instance item support becomes a real requirement.

🔦 Context

PR #7559 added defineObservableProperty to avoid duplicate observerMap accessors while keeping replacement arrays observable. This follow-up documents the assumptions behind that idempotency check so future changes do not accidentally broaden or break the behavior.

Searched existing issues for overlapping observerMap accessor idempotency reports and did not find a duplicate.

💻 Examples

if (!Observable.getAccessors(targetObject).some(accessor => accessor.name === key)) {
    Observable.defineProperty(targetObject, accessor);
}