feat(proxylogs): show registry proxy name in proxy log columns

[tiangao88]

Problem

The Proxy Logs page (/dashboard/logs/proxy) renders the "Proxy" column as
host:port. When several registry entries share one gateway (e.g. a
multi-country residential pool), every row shows the same string and operators
cannot tell which configured proxy handled a request. The registry already
stores a human-meaningful name per proxy.

Cause

toRegistryProxyResolution (mappers) attaches name to the runtime proxy
object, but ProxyInfo in src/lib/proxyLogger.ts does not carry it — the
name is dropped at the persistence boundary and never rendered.

Change

• Ship proxy_name as migration 181_proxy_logs_proxy_name.sql, with the
  version-keyed idempotency check in migrationRunner (same shape as 179's
  upstream_status), so fresh installs and existing databases both get the
  column. The ensureProxyLogsColumns ALTER heal stays as the boot-time
  belt-and-suspenders. src/lib/db/core.ts is deliberately left untouched —
  its frozen file-size ratchet stays at 1770 lines.
• Carry name through ProxyInfo; persist and hydrate it.
• Render the name in the ProxyLogger table column and the ProxyLogDetail pane,
  falling back to host:port (and type://host:port) for legacy/direct rows.
• Include the name in the [ProxyEgress] log line (new formatProxyEgressConsoleLine
  formatter) and in the log search.

Tests

tests/unit/proxy-logger-name.test.ts — name carried on the log entry,
persists + hydrates from SQLite, search matches name, legacy no-name rows
hydrate cleanly. tests/unit/migration-181-proxy-logs-proxy-name.test.ts —
the migration adds the column on a database that lacks it, and is recorded
without re-adding it when the boot heal already ran (no cross-talk with 179).
Related proxy-logger + migration suites remain green (14/14). The detail-pane
label moved into a module-scope helper so the component's cyclomatic
complexity stays inside the ratchet.

Notes

Non-breaking: existing rows without a name still render host:port.
Rebased onto the current release/v3.8.51 tip (0cc016936); changelog
fragment in changelog.d/features/.

[diegosouzapw]

Nice, contained fix for a real operator pain point (indistinguishable proxy rows when several
registry entries share a gateway) — the self-heal ALTER TABLE pattern for the new column was
the right call given how far behind this branch is from the current tip; it sidesteps any
migration-numbering collision entirely. Ran your test suite in isolation: 4/4 pass, and a dry
merge against the current release/v3.8.51 tip shows zero conflicts despite the branch being
quite old. Two things needed before merge: rebasing/retargeting onto the current release branch
(this PR still targets the now-superseded release/v3.8.50) so CI runs against the real base,
and a changelog fragment. Once that's done this looks ready to go.

[diegosouzapw]

Thanks @tiangao88 — merging via the release merge-train. Validated in local merge-train (merge-train-20260918-130526-suite.log) on the devbox @ train tip 28fb420c9ad860ba275294ebb4ebbecb9da83318 with the sibling PRs of this batch: static gates green; changed-area node:test 293/294 (0 failing) + vitest 482/482 (fast parity — full suite ran today on the tip via the base-red and 3b trains). Merged --admin per merge-gates §7.