read_log serves the pre-5.2 frozen hdb.log after an in-place 5.2.0 upgrade — live logging moved to system.log

### Symptom

On an instance upgraded in-place to 5.2.0, the `read_log` operation returns only entries written **before** the 5.2.0 upgrade — indefinitely. New boots, warnings, and errors never appear. Remote diagnosis via `read_log` silently reads a dead file while looking current (this misdirected a multi-day live investigation).

### Cause (observed on a Fabric-hosted 5.2.0 instance, harper-pro image)

Since 5.2.0 the live log file is `system.log`; `hdb.log` receives nothing after the upgrade boot (file mtime frozen at that boot). `read_log` still reads `hdb.log`. In-container listing: `hdb.log` 797 bytes frozen at the upgrade timestamp; `system.log` 400KB and current.

Secondary observation: `read_log` output appears identical across cluster nodes (replicated source?), which compounds confusion when diagnosing a single node.

### Expected

`read_log` follows the active log destination on 5.2+ (or merges/redirects), and documentation states the file split. Full timeline/evidence available on request.

Start at the read_log entry point and compare the log source used after a 5.2.0 upgrade with the reported hdb.log and system.log behavior. Done means read_log exposes current post-upgrade entries and the file split is documented; check for existing read_log tests before adding regression coverage.

Written by the indexing model from the issue text.