[DocDB] Tserver UI not showing the frontiers (specifically TTL) correctly for the SST files.

Jira Link: DB-14417

When this matters

The per-tablet RocksDB page in the tserver web UI lists each SST file along with its boundary "frontier" values, which include the file's TTL/expiration information.

An operator reaches for this page when investigating why data that should have expired is still on disk — for example, a table with a TTL configured where old SST files are not being cleaned up by TTL-based file expiration. Such files stay large, can inflate query latency, and the operator wants to confirm, per file, what expiration time the storage engine has recorded for it, and therefore whether the file is eligible to be expired and compacted away.

What it currently does

The page does surface a TTL/expiration frontier per file, but in this scenario it is not usable:

• For files whose data expires via a table-level TTL (e.g. a table-wide default TTL — the common case for time-series tables), the displayed expiration is a placeholder rather than the file's effective expiration. The frontier reflects only per-write (value-level) TTLs, so a file governed by a table-level TTL shows no meaningful expiration at all.
• When an expiration time is present, it is rendered as a raw internal timestamp (a large integer) rather than a human-readable date/time, so an operator cannot tell at a glance when the file is due to expire.

Net effect: the page that should answer "why isn't this TTL'd file being cleaned up?" does not give the operator a readable, correct expiration time to reason about.

Ask

Show the SST file frontiers — and the TTL/expiration in particular — in a form an operator can actually use to reason about file expiration: reflect the effective expiration (accounting for table-level TTL) and render times in a human-readable form.