feat(devtools): Register event subscriptions on-demand

[Joshua Smithrud (Josmithr)]

Previously, devtools would (upon initialization) immediately register on-op event listeners on all provided root DDSs and immediately begin broadcasting data visualization messages on the window (regardless of whether or not the browser extension was running and listening).

This PR updates devtools to register these listeners lazily on demand. This leverages the existing laziness that was implemented for nested DDSs, such that we only register event listeners when we receive the GET_DATA_VISAUALIZATION message from the browser extension.

A corresponding CLOSE_DATA_VISUALIZATION message has been added, which the extension now uses to indicate when it is done needing data from the client. The client leverages this alongside simple ref-counting to unsubscribe DDS listeners when there is no longer interest in data.

• Note: this PR does not address the potential listener leak that can occur if a consumer requests data events but fails to send the corresponding close message. But since the code previously never de-registered listeners once initially registered, this is still a strict improvement. We can follow up on this in the future as needed.

Note that there are no cross-layer compat issues here between the devtools client library and the extension.

client ↓ \ extension →	Old extension (doesn't send CLOSE message)	New extension (sends CLOSE message)
Old client (eager broadcast, no CLOSE handler)	Baseline. Eager broadcasting of all reachable roots; subscriptions never released. Works as before.	Compatible. Old core ignores the unrecognized CLOSE_DATA_VISUALIZATION. Still eager; view filters incoming DATA_VISUALIZATION by fluidObjectId and detaches handlers on unmount, so extra/stale broadcasts are harmless. No regression.
New client (on-demand, ref-counted, CLOSE handler)	Compatible, strict improvement. Nothing broadcasts until the view sends GET_DATA_VISUALIZATION. Old view never sends CLOSE, so each subscribed node stays subscribed after collapse — subscription leak, but behavior is no worse than the Old-core baseline (which monitored everything unconditionally).	Fully intended behavior. On-demand subscribe on expand/mount, balanced unsubscribe on collapse/unmount. Monitoring (and broadcasting) occurs only while a view is actively displaying an object. No leak (assuming proper view teardown).

[github-actions]

Hi! Thank you for opening this PR. Want me to review it?

Based on the diff (592 lines, 10 files), I've queued these reviewers:

• Correctness — logic errors, race conditions, lifecycle issues
• Security — vulnerabilities, secret exposure, injection
• API Compatibility — breaking changes, release tags, type design
• Performance — algorithmic regressions, memory leaks
• Testing — coverage gaps, hollow tests

How this works

• Adjust the reviewer set by ticking/unticking boxes above. Reviewer toggles alone don't trigger anything.

• Tick Start review below to dispatch the review fleet.

• After review finishes, tick Start review again to request another run — it auto-resets after each dispatch.

• This comment updates as new commits land; your reviewer selections are preserved.

• Start review

[Copilot]

Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.

[Ji Kim (jikim-msft)]

NIT: While renaming existing types to DataVisualizerEvents, there's a dangling reference to {@link SharedObjectListenerEvents | "update"} event at Line 511 of DataVisualization.ts. Might as well fix it here for consistency

Joshua Smithrud (@Josmithr)

[github-actions]

Bundle size comparison

Base commit: b17b7e642301e14bdb5912b667a34f0c4a74cfdb
Head commit: ec51d4acf2a16d3fc8749c023396749ff0ce584a

Notable changes

No bundles changed by ≥ 500 bytes parsed.

Per-bundle deltas

@fluid-example/bundle-size-tests

• azureClient.js: parsed 619063 → 619119 (+56), gzip 164813 → 164858 (+45)
• odspClient.js: parsed 591789 → 591845 (+56), gzip 158906 → 158947 (+41)
• aqueduct.js: parsed 525587 → 525622 (+35), gzip 140709 → 140738 (+29)
• fluidFramework.js: parsed 393001 → 393022 (+21), gzip 111618 → 111634 (+16)
• sharedTree.js: parsed 382388 → 382402 (+14), gzip 109007 → 109016 (+9)
• containerRuntime.js: parsed 303937 → 303951 (+14), gzip 83213 → 83221 (+8)
• sharedString.js: parsed 175984 → 175991 (+7), gzip 49445 → 49452 (+7)
• experimentalSharedTree.js: parsed 160798 → 160798 (0), gzip 45804 → 45804 (0)
• matrix.js: parsed 159845 → 159852 (+7), gzip 45411 → 45418 (+7)
• loader.js: parsed 145221 → 145235 (+14), gzip 39052 → 39066 (+14)
• odspDriver.js: parsed 104329 → 104350 (+21), gzip 32649 → 32658 (+9)
• directory.js: parsed 66616 → 66623 (+7), gzip 18532 → 18540 (+8)
• 748.js: parsed 58793 → 58793 (0), gzip 17826 → 17826 (0)
• map.js: parsed 46709 → 46716 (+7), gzip 14310 → 14317 (+7)
• odspPrefetchSnapshot.js: parsed 45642 → 45656 (+14), gzip 15276 → 15284 (+8)
• 594.js: parsed 44493 → 44493 (0), gzip 13744 → 13744 (0)
• summarizerDelayLoadedModule.js: parsed 30753 → 30753 (0), gzip 7767 → 7767 (0)
• socketModule.js: parsed 26477 → 26484 (+7), gzip 7885 → 7894 (+9)
• createNewModule.js: parsed 12480 → 12480 (0), gzip 4786 → 4786 (0)
• summaryModule.js: parsed 3797 → 3797 (0), gzip 1860 → 1860 (0)
• connectionState.js: parsed 724 → 724 (0), gzip 429 → 429 (0)
• sharedTreeAttributes.js: parsed 666 → 673 (+7), gzip 432 → 441 (+9)
• debugAssert.js: parsed 429 → 429 (0), gzip 299 → 299 (0)
• FluidFramework-HashFallback.js: parsed 422 → 422 (0), gzip 316 → 316 (0)