Rename clicktrack.js — a content blocker was eating it and killing the app

A file called `clicktrack.js` matches the click-tracking telemetry patterns that
EasyPrivacy and similar lists block by substring. In a browser with a content
blocker the request never completes, and because it is a module import that
takes the entire graph with it: main.js never runs, no handler is ever bound,
and every control in the UI sits there looking correct and doing nothing.

The failure is unusually expensive to diagnose because everything else looks
healthy. The dev server returns 200 with the right MIME type, curl fetches it
fine, node imports it fine, and the app loads perfectly in any browser without a
blocker — which is how it passed every check here. Only the console names it,
and only as one line about a module that failed to load.

Renamed to metronome.js, which is also the better name for what it does. The
button id went with it, since cosmetic filter rules can hit ids too.

The general rule, recorded at the top of the file: anything shipped to a browser
and named like tracking will be treated as tracking. Avoid click, track,
analytics, pixel, beacon and ad in filenames and URL paths, however honest the
code behind them is.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

flow-state/index.html

@@ -80,6 +80,73 @@
 
     <input type="file" id="file-input" accept="audio/*" hidden>
     <audio id="audio" hidden></audio>
+
+    <div id="boot-error" hidden>
+        <div class="be-inner">
+            <div class="be-title">the app did not start</div>
+            <div class="be-body">
+                <p>Every control is inert because <code>main.js</code> never ran — the
+                   markup you are looking at is the static page. Nothing is wrong with
+                   your audio file.</p>
+                <pre id="be-detail"></pre>
+                <p class="be-hint">A module that fails to load takes the whole graph
+                   with it, and the usual cause is a fetch that hit the dev server while
+                   it was restarting. A hard reload normally fixes it; if it does not,
+                   restart <code>npm run dev</code>.</p>
+            </div>
+        </div>
+    </div>
+
+    <script>
+        // BOOT GUARD. Loaded before the module and deliberately not a module
+        // itself, so it survives whatever kills the module graph.
+        //
+        // A module that fails to load — a 404, a MIME error, a syntax error, a
+        // dev server caught mid-restart — aborts main.js silently. The page
+        // still renders, every button is still there, and not one of them is
+        // wired to anything. That failure cost a real debugging session: the UI
+        // looked correct and simply did nothing, which is the most expensive
+        // way for a front end to break.
+        (function () {
+            var shown = false;
+            function show(detail) {
+                if (shown) return;
+                shown = true;
+                var box = document.getElementById('boot-error');
+                var pre = document.getElementById('be-detail');
+                if (pre) pre.textContent = detail || 'no detail available';
+                if (box) box.hidden = false;
+            }
+
+            // A module that never executes never sets this.
+            window.addEventListener('error', function (e) {
+                // Module load failures arrive as an error event on the script
+                // element rather than as a window error with a message.
+                if (e && e.target && e.target.tagName === 'SCRIPT') {
+                    show('failed to load: ' + (e.target.src || 'unknown module') +
+                         '\n\nOpen the console — the first "Loading failed for the ' +
+                         'module" line names the file that actually broke.');
+                } else if (e && e.message) {
+                    show(e.message + (e.filename ? '\n  at ' + e.filename + ':' + e.lineno : ''));
+                }
+            }, true);
+
+            window.addEventListener('unhandledrejection', function (e) {
+                var r = e && e.reason;
+                show('unhandled rejection during startup:\n' + ((r && r.stack) || r));
+            });
+
+            // The backstop for the case no error event fires at all: if the app
+            // has not announced itself in a few seconds, it is not going to.
+            setTimeout(function () {
+                if (!window.__FLOW_STATE_READY__) {
+                    show('main.js did not finish starting within 8 seconds and no ' +
+                         'error was reported.\n\nCheck the console for the first red ' +
+                         'line — a failed module import is the usual cause.');
+                }
+            }, 8000);
+        }());
+    </script>
     <script type="module" src="/src/main.js"></script>
 </body>
 </html>