Tear down v1 once the old clients have drained

[bradgessler]

Now that terminalwire-rails 2.x is a true drop-in for v1 (an app bumps the gem
version and redeploys — no code changes), v1 only exists to keep old clients
working. The v1 Ruby/Tebako client and any pre-cutover installs still speak v1, so
we hold onto the v1 server until they've drained. This issue records what to remove
and how to know it's safe.

When it's safe to tear down

v1 is dead weight once no clients connect over the v1 wire anymore. Concretely:

• v1 WebSocket upgrades (no terminalwire.v2 subprotocol) at terminalwire.com
  have fallen to ~zero over a sustained window (check the dispatcher / access logs).
• The old Ruby/Tebako client is fully retired — the installer ships only the Go
  client (which speaks v2), and the published v1 gems are yanked/EOL'd so no new
  installs land on v1.
• No remaining server pins a v1-only setup (see "Who still uses v1" below).

Until then, keep v1. The drop-in already makes dual apps work without touching
v1, so there's no cost to leaving it in place.

Who still uses v1 today

• terminalwire.com — routes through Terminalwire::V2::Rails.dual_terminal(MainTerminal),
  which serves v2 to v2 clients and falls back to the v1 handler for everyone else.
  It pins an old revision, so changes to main don't disturb it until it redeploys.
  When we tear down v1, terminalwire.com migrates to the same v2-only drop-in ogplus
  uses: match "/terminal", to: Terminalwire::Rails::Thor.new(MainTerminal).
• opengraphplus.com — already v2-only drop-in (no v1 gems loaded). Not affected.

What to remove (the teardown)

1. Delete the dead v1 sub-gems:
   • gem/terminalwire-client (the Ruby/Tebako client — replaced by the Go client)
   • gem/terminalwire-server (the v1 WebSocket server)
   • gem/terminalwire (the v1 meta-gem, no dash)
   • gem/terminalwire-core — only if nothing else depends on it (the v2 terminalwire
     gem does not; it's self-contained).
   • Keep gem/terminalwire-rails — it's now the v2 Rails integration.
2. Delete the Tebako build machinery: containers/ubuntu-tebako/, build/, and any
   Rake tasks / CI that build the Tebako client.
3. Strip the v1 fallback from the gem (v2/ruby/lib/terminalwire/v2/rails.rb):
   remove dual_terminal, Dispatcher, and default_v1 (they only exist to reach the
   v1 handler). Keep terminal, VersionEndpoint (the v2-default forward-compat seam),
   Session, the Thor mixin, and the drop-in v1-name aliases at the bottom of the file
   (those make Terminalwire::Thor / Terminalwire::Rails::Thor resolve to v2 — they're
   the drop-in surface, not v1).
4. Migrate terminalwire.com off dual_terminal to the v2-only drop-in (see above),
   and drop the v1 gems from its Gemfile.
5. Update docs / V2_SELF_HOSTING.md to drop the dual-protocol story.

Why drop-in makes this low-stakes

The v1 API names (Terminalwire::Thor, Terminalwire::Rails::Thor, Terminalwire::Rails::Session)
are defined in terminalwire/v2/rails.rb, guarded with defined?. A v2-only app gets
the v2 implementations; a transitional app that still loads the v1 gems keeps v1's
classes and uses dual_terminal explicitly. So tearing down v1 is mostly deletion —
the v2 surface is already the default for anything that isn't explicitly dual.

Ref: drop-in landed in c2e256a; verified on opengraphplus.com (original v1 wiring,
v2 over the wire).