chore(cli): remove dead ArgusTop and clarify TopCommand wiring

[rlaope]

Summary

ArgusTop.java carried its own main loop that mirrored TopCommand byte-for-byte (cursor hide → connect → fetch → render → stdin q-check → sleep → unhide). Nothing reached it:

• The fatJar's Main-Class is ArgusCli, not ArgusTop
• No test referenced it
• TopCommand re-implements the same flow inline rather than delegating
• Its only mentions outside the file itself were a stale TopCommand docstring and a docs/architecture.md line

This PR drops ArgusTop.java (108 lines), updates TopCommand's docstring to describe what it actually does, and tightens docs/architecture.md to drop the "Legacy" framing — ArgusClient / TerminalRenderer / MetricsSnapshot are still load-bearing for TopCommand.

Why this and not a "Ticker" abstraction

This change was originally surveyed as part of a "tick-loop deepening" candidate. On closer inspection the three remaining tickers — HarnessEngine (session-bounded ScheduledExecutorService + CountDownLatch), the server's long-running EventBroadcaster (scheduleAtFixedRate with start/stop), and ZgcCommand.runWatch (fixed-iteration for-loop with shutdown hook) — serve genuinely different lifecycles. A shared Ticker abstraction would force a single-adapter seam at every site, which is the shallow-module trap to avoid (one adapter = hypothetical seam, not a real one). The honest payoff in this area was the dead-duplicate removal here.

Test plan

• ./gradlew build -x integrationTest passes after deletion
• argus top still routes through TopCommand (unchanged path)
• Smoke argus top --host=… --port=… against a running argus-server on the user side