Fix #1306: drop misleading right-click hint on the public Servers page

[rumblefrog]

Fixes #1306.

Summary

The Servers page header (?p=servers) used to render an admin-only
hint that promised a right-click context menu on each expanded
server card's player rows ("Right-click a player on an expanded card
to kick, ban, or message them"). The supporting JS lived in
web/scripts/sourcebans.js's LoadServerHost(...) helper, which
deleted the per-row AddContextMenu(...) call along with the rest
of the file at #1123 D1. The v2.0.0 page_servers.tpl rewrite never
re-registered the menu — so the help text described a feature that
no longer ships, and right-clicking a player row falls through to
the browser's native context menu.

Restoring the menu would need an extra RCON status round-trip per
server card (the SourceQuery GetPlayers() UDP response does not
carry SteamIDs) — doubling per-card latency and only working for
admins mapped to servers with rcon — which is out of scope for this
public surface. The kick/ban/mute UX is reachable from
?p=admin&c=kickit, ?p=admin&c=blockit, and the per-row
affordances on the public ban / comm lists, so admins are not
without a path. This PR takes the issue's "drop the help text"
option and burns the dead supporting code in the same commit so a
future contributor can't accidentally re-add the hint without the
underlying menu.

Changes

• Drop the <p data-testid=\"servers-rcon-hint\"> block from
  page_servers.tpl; replace it with an in-template comment
  pointing future contributors at the missing wiring so the hint
  isn't accidentally re-added without it.
• Drop IN_SERVERS_PAGE and access_bans from ServersView (the
  hint conditional was their only consumer in page_servers.tpl)
  and update page.servers.php and page.home.php accordingly.
  page.home.php now computes access_bans directly via
  HasAccess(...) and passes the literal false for
  IN_SERVERS_PAGE (the dashboard always was the false case).
• Burn the dead context-menu helpers: delete contextMenoo.js,
  remove sb.contextMenu and the global AddContextMenu shim from
  sb.js, and drop the matching SbContextMenuItem /
  contextMenoo / AddContextMenu ambient declarations from
  globals.d.ts. None had call sites anywhere in the panel.
• Add a paired anti-pattern entry to AGENTS.md so a future
  contributor can't reintroduce just the hint copy without the
  underlying menu (and the SteamID extension to
  api_servers_host_players it would need).
• Update ARCHITECTURE.md to drop the deleted contextMenoo.js
  row from the web/scripts/ listing and the per-file role table.
• Add ServerListHintRegressionTest (web/tests/integration/)
  pinning two invariants: the rendered HTML for ?p=servers (admin
  • at least one seeded server) does NOT contain the hint testid or
    copy, and Sbpp\View\ServersView's constructor no longer accepts
    the IN_SERVERS_PAGE / access_bans named params. Mirrors the
    AdminAdminsSearchTest harness shape (real Smarty + ob_start
    capture against the production page handler).

Test plan

All five quality gates run locally (mirroring CI) — all pass:

• ./sbpp.sh phpstan — clean (no new errors / no baseline drift)
• ./sbpp.sh test — 405 tests pass (ServerListHintRegressionTest
  green; the two new methods cover the rendered-HTML assertion and
  the ServersView constructor signature)
• ./sbpp.sh ts-check — clean (touched web/scripts/sb.js +
  web/scripts/globals.d.ts)
• ./sbpp.sh composer api-contract — diff stays clean (no API
  handler changes)
• CI=1 ./sbpp.sh e2e — full Playwright suite (192 specs,
  workers: 1 to match CI) passes; the hint never had its own
  spec but the existing servers-page chrome specs still cover the
  surface and didn't regress

Manual verification:

• Hit ?p=servers as admin/admin with seeded servers — the
  misleading hint no longer appears in the header strip.
• Hit ?p=home as admin/admin — dashboard renders unchanged
  (the dashboard never showed the hint anyway, since
  IN_SERVERS_PAGE was always false there; verified the
  explicit false literal preserves that behaviour).