fix(app): restore dev WS URL rehosting lost in the workflows revert

[SawyerHood]

Summary

The workflows revert (ee01a53) returned apps/app/src/lib/ws.ts and terminal-websocket-url.ts to a state predating da16d3c, silently undoing the dev WS rehost fix as collateral damage.

Symptom: on a remote device (BB_DEV_APP_HOST=0.0.0.0, e.g. over tailscale), the app loads and /api works through the same-origin vite proxy, but the realtime socket dials the baked ws://localhost:<server-port>/ws — the device's own loopback — and never connects. No live updates arrive; timelines only move on refetch triggers (pressing stop, sending another message, window refocus). Provider-independent; it presents as "responses don't appear until I press stop and send another message."

Fix

Reapplies da16d3c's hunks verbatim: swap only the hostname of the baked dev URL for window.location.hostname on the realtime and terminal sockets. The intentional parts of the revert (dropping workflow subscription refcounting in the same file) are untouched.

Verification

• turbo run typecheck --filter=@bb/app ✅
• Repro + fix verified end-to-end in a dev instance: before the fix, a browser pointed at the tailnet IP received zero realtime frames after subscribe (responses only appeared on refetch); after, the realtime socket dials ws://<page-host>:20694/ws and a mid-conversation agent response rendered live (~8s) with no interaction.

🤖 Generated with Claude Code

[SawyerHood]

Superseded by #116 (cd954fd), which landed the same repair as an explicit opt-in: BB_DEV_REMOTE=true binds the vite dev app to all interfaces and routes dev WebSockets (realtime + terminal) to the page hostname on the server port via the new buildDevWebSocketUrl helper, while non-remote dev deliberately keeps the fixed ws://localhost:<port> origin. This PR's unconditional rehost of __BB_DEV_WS_URL__ would fight that design, so closing rather than rebasing. The remote-dev flow this fixed is covered by BB_DEV_REMOTE=true on current main.