FOLLOW-UP: Document data-lvt-force-update escape hatch (from PR #108)

[adnaan]

Context

This follow-up was identified during the review of PR #108 (per-op targeted DOM mutation for range diff ops).

Source PR: #108
Suggested by: @claude[bot] (PR review, round-1 comment)

Task description

The livetemplate-client.ts updateDOM optimization that skips wrapper-wide directive scans when nodesAddedThisRender === 0 && !directiveTouchedThisRender has data-lvt-force-update as the user-facing escape hatch — for the rare case where the server adds a new directive attribute via attribute morph that morphdom doesn't see as a "new node added" event.

The behavior is documented as an inline comment in livetemplate-client.ts, but isn't in the user-facing docs at livetemplate/livetemplate docs/references/. Without that, users hitting the edge case (mysteriously missing event listeners) won't know to add data-lvt-force-update.

The round-6 fix to directiveTouchedThisRender (only flag when an lvt-* attribute is NEW on toEl, not when it's already present) substantially reduced the scope of this issue — most attribute-only renders that introduce a directive will now be caught. But data-lvt-force-update is still relevant as the explicit override.

Original comment excerpt

The nodesAddedThisRender > 0 optimization skips post-render directive scans for attribute-only changes... The only escape hatch is data-lvt-force-update, which is not publicly documented. Worth adding to user-facing docs before shipping, otherwise this shows up as mysterious missing event listeners.

Suggested action

Add a section to livetemplate/livetemplate docs/references/client-attributes.md (or wherever per-attribute docs live) covering:

• What data-lvt-force-update does
• When to use it (attribute-only morphs that introduce a new lvt-* directive)
• Example template snippet

This is a livetemplate (server) repo docs change, but tracked here since the underlying behavior originated in the client.

---

Created by /prmonitor from PR #108 review comments.