[iris] Update iris client to fetch logs from /system/log-server directly

[rjpower]

🤖 Filed as cleanup during the log-service-subprocess PR review.

The log server now runs on its own port (see commit bdcc036f8, "iris: host log server on its own port in all modes") and advertises its address via the /system/log-server endpoint. The dashboard currently proxies FetchLogs for backward compatibility:

• lib/iris/src/iris/cluster/controller/dashboard.py:266-283 — mounts LogServiceWSGIApplication on the controller's port and aliases /iris.cluster.ControllerService/FetchLogs → /iris.logging.LogService/FetchLogs for old clients.

Task

• Update the iris client (CLI + dashboard JS) to resolve the log server address from the controller's /system/log-server system endpoint and call FetchLogs against it directly.
• Remove the LogServiceWSGIApplication mount and the backward-compat /iris.cluster.ControllerService/FetchLogs alias from dashboard.py.
• Drop the corresponding tests in lib/iris/tests/cluster/controller/test_dashboard.py:848-867.
• Once this lands, RemoteLogService can be deleted entirely (it only exists to back the dashboard's proxy mount) — the controller's own internal fetch_logs calls can use LogServiceClientSync directly.

Notes

• Verify auth still works end-to-end: the log server's auth interceptors are set up in lib/iris/src/iris/log_server/main.py.
• The iris CLI paths that currently call ControllerService/FetchLogs will need to be audited — grep ControllerService/FetchLogs or the client-side wrapper.

[claude]

🤖 Plan:

• Research codebase and assess scope
• Run duplicate-work preflight
• Post root cause analysis and proposed approach

Research

This issue is a follow-up cleanup for PR #4682 (iris: move log service to a separate subprocess), which adds a standalone LogService on its own port. PR #4682 is approved but not yet merged — this work depends on it landing first.

Currently, all LogService clients (LogServiceClientSync) hardcode the controller URL. The controller dashboard mounts LogServiceWSGIApplication and a backward-compat alias to proxy log requests. The goal is to have clients discover the log server address via the /system/log-server system endpoint and call it directly, then remove the proxy.

Relevant code

• dashboard.py#L267-L276 — LogServiceWSGIApplication mount + compat alias to remove
• dashboard.py#L298 — route mount to remove
• process_status.py#L91 — CLI creates LogServiceClientSync(controller_url)
• bug_report.py#L123 — bug report creates LogServiceClientSync(controller_url)
• remote_client.py#L71-L75 — RemoteClusterClient creates LogServiceClientSync(controller_address)
• useRpc.ts#L96-L113 — dashboard JS calls FetchLogs via relative URL to same origin
• worker.py#L445-L460 — reference impl: worker already resolves /system/log-server via ListEndpoints
• test_dashboard.py#L847-L874 — two compat tests to remove

Proposed approach

Prerequisite: merge PR #4682 first.

Python clients (straightforward, ~50 lines):

1. Add a helper (e.g. resolve_log_server(controller_client) -> str) that calls ListEndpoints(prefix="/system/log-server", exact=True) and returns the address. The worker already does this pattern in worker.py#L445-L460.
2. CLI process_status.py: create ControllerServiceClientSync, resolve log server, create LogServiceClientSync pointing to that address. Fall back to controller URL if resolution fails (graceful degradation for old controllers).
3. CLI bug_report.py: same pattern.
4. RemoteClusterClient.__init__: resolve log server address lazily (at first log call) since ListEndpoints requires the server to be up.

Dashboard removal (~15 lines removed):

1. Delete LogServiceWSGIApplication instantiation (L267-268), compat alias (L270-276), and route mount (L298) from dashboard.py.
2. Remove the LogServiceWSGIApplication import (L47).
3. Drop log_service param from ControllerDashboard.__init__ if it becomes unused.

Tests (~28 lines removed):

1. Delete test_fetch_logs_backward_compat_proxy and test_fetch_logs_backward_compat_proxy_proto_binary from test_dashboard.py.

Dashboard JS (needs design decision, ~50-100 lines):
This is the non-trivial part. The dashboard JS currently makes relative fetch() calls to /iris.logging.LogService/FetchLogs against the same origin (controller port). Once the LogService mount is removed, browser clients must call the log server on a different port. This raises:

• CORS: the log server runs on a different origin (different port). Need Access-Control-Allow-Origin + credential forwarding.
• Discovery: browser needs the log server URL. Options: (a) extend /auth/config with logServerUrl, or (b) call ListEndpoints RPC from JS.
• Auth: the log server (per PR iris: move log service to a separate subprocess #4682) now has its own auth interceptors, so session cookies/tokens must be forwarded cross-origin.

Recommendation: extend the existing /auth/config response with the log server URL. This avoids an extra RPC round-trip and keeps the JS change small — useLogServiceRpc just needs to prefix the resolved base URL instead of using a relative path.

Duplicate-work check: PR #4682 is the only overlapping work. PR #4231 (Remove deprecated GetTaskLogs RPC) is unrelated. No other PRs target these files.