Fix dev tools event listener leak on Turbo navigation

[marcoroth]

This pull request fixes the browser performance degradation reported when debug_mode is enabled on an application using Turbo navigation. Every Turbo visit added a new batch of document event listeners, and none of them were ever removed.

initializeDevTools was registered on three separate Turbo events, so a single navigation invoked it three times, and each invocation constructed a fresh HerbOverlay:

document.addEventListener("turbo:load", initializeDevTools)
document.addEventListener("turbo:render", initializeDevTools)
document.addEventListener("turbo:visit", initializeDevTools)

Nothing tore the old overlays down. ReActionViewDevTools#destroy only removed the .herb-floating-menu element from the DOM, which strips the UI while leaving every handler attached and every overlay instance live and still responding to Turbo events.

Follow-up once the Herb fix ships

marcoroth/herb#2081 addresses the remaining leaks inside @herb-tools/dev-tools itself. The document click listener that setupMenuToggle adds on every navigation, and the absence of any destroy on HerbOverlay and ErrorOverlay.

That fix does not reach users through a gem upgrade. rollup.config.js sets external: [] alongside nodeResolve(), so @herb-tools/dev-tools and @herb-tools/client are compiled directly into app/assets/javascripts/reactionview-dev-tools.{umd,esm}.js, and those vendored bundles are the only JavaScript the gem serves.

Picking up the Herb fix therefore needs, in order:

1. Bump @herb-tools/dev-tools and @herb-tools/client off ^0.10.3
2. Delegate ReActionViewDevTools#destroy to the new HerbOverlay#destroy instead of hand-removing .herb-floating-menu, which fixes the public initReActionViewDevTools and manual teardown paths that this pull request deliberately leaves alone.

Depends on marcoroth/herb#2081

Resolves #108