feat(logs): add Logs pillar with bounded log tails

[thiagoesteves]

What

Adds a Logs pillar: a bounded, read-only tail of the selected node's log files during an incident - the web equivalent of observer_cli's log tail pane.

• ObserverWeb.Logs.list_handlers/1 discovers the file-backed :logger handlers on the target node (:logger.get_handler_config/0); console handlers are skipped.
• ObserverWeb.Logs.tail/3 reads at most the selected tail size (16 KB to 1 MB, hard-capped) from the end of the file via a single stdlib-only RPC - a pre-parsed :erl_eval expression opens/preads/closes on the remote node, so it works against any OTP node regardless of the observer_web version there (same principle as ObserverWeb.SystemInfo).
• The page offers service, log file and tail size selectors plus REFRESH, and shows file size / truncation chips above the tail pane.

Security notes

• Only files exposed by the node's logger handler configs can ever be requested; the form's file value is validated against that list on every read (selected_file/2 falls back to the first known handler, and ObserverWeb.Logs.tail/3 re-checks server-side), so free-form paths from the browser are never opened.
• Reads are bounded and use :raw mode, keeping the descriptor inside the rpc process.

Why

Part of the roadmap derived from comparing ObserverWeb against OTP observer, observer_cli and Phoenix LiveDashboard: observer_cli proved how useful a safe bounded log view is during incidents, and it sits naturally next to the Crashdump pillar.

Risk assessment

• Impact: new read-only pillar; no changes to existing pages.
• Blast radius: additive - new context module and page, plus three small wiring edits (page resolution, nav list, icon).
• Regression risk: low - bounded reads, allowlisted files, existing Rpc adapter; suite green (408 tests, 95.8% coverage), credo/sobelow/dialyzer/format clean. Note: there is a pre-existing intermittent failure in version/tracing tests that reproduces on main; a separate fix PR will follow.
• Rollback plan: revert the commit; no config or data involved.

Checklist

• mix test green (408 tests)
• mix coveralls 95.8% (threshold 95%)
• mix credo --strict, mix sobelow, mix dialyzer, mix format --check-formatted clean
• Small focused diff, no leftover debug output

🤖 Generated with Claude Code

[thiagoesteves]

Pushed a fix for the crash reported while testing: selecting a service with no file-backed logger handlers rendered an empty Log File select, so the change payload had no "file" key and the %{map | key} update in handle_info(:logs_refresh, ...) raised KeyError, killing the LiveView. Form params are now built with Map.put, with a regression test that reproduces the exact crash without the fix.

Also added the missing documentation: an installation-guide "Logs" section and a ObserverWeb.Logs moduledoc section covering the Elixir 1.15+ file-handler config (config :my_app, :logger, [{:handler, ...}] + Logger.add_handlers/1) and the runtime :logger.add_handler/3 alternative - nothing needs configuring on the Observer Web side, the page follows whatever file handlers the observed node has.

[thiagoesteves]

Added a dev.exs setup for local testing: every instance attaches a file-backed logger handler writing to /tmp/observer_web_dev_<node>_<random>.log (random suffix so multiple side-by-side nodes never collide), with a 5s heartbeat producing info/warning/error lines so the tail always has fresh content. OBSERVER_WEB_DEV_LOG_FILE=false disables it, OBSERVER_WEB_DEV_LOG_HEARTBEAT_MS tunes the heartbeat. Verified by booting the dev server and tailing the generated file through the Logs page.

[thiagoesteves]

Follow-up from local testing: the dev file handler was writing ANSI color codes ([33m/[0m) into the log because Logger.Formatter enables colors when running in a terminal. The dev.exs formatter now disables colors, and the Logs pane also strips ANSI sequences at display time - real-world log files written by color-enabled formatters have the same issue, so the pane stays legible either way.

[thiagoesteves]

Logs pane UX rework after visual testing:

• The tail is parsed into log entries (a new entry starts at a time/date/Erlang-report head; stack traces attach to the entry above) and each entry renders as one truncated line.
• Disclosure rows follow a filled/hollow marker scheme: ▶ filled + clickable when there is more to expand (multi-line entries, or long single lines that truncation clips), ▷ hollow + inert when the line is all there is. Multi-line entries also show a dimmed …, and error/warning summaries are color-coded.
• The pattern is extracted into a reusable Core.disclosure component so other tables (tracing results, ETS previews) can adopt it later.
• dev.exs heartbeat now emits a multi-line fake crash report and a deliberately long single-line message to exercise the UI, and fixes a silent filter: the primary logger level (:warning from config.exs) dropped info entries before any handler saw them - the dev server lowers it to :info while pinning the console handler back to :warning.

[thiagoesteves]

Added auto refresh: a Refresh interval selector (Paused/2s/5s/10s, default 5s) driven by the same generation-counted tick chain the Network pillar uses, and the entries pane now follows the newest entries via the existing ScrollBottom hook - it re-sticks to the bottom after each refresh unless the user has scrolled away, in which case the position stays pinned.