Fix: Recent Activity rows intermittently dropping AM/PM

[Brandon-Haney]

Problem

A single row in the dashboard's Recent Activity feed could render its time without the AM/PM suffix while the other rows in the same run kept theirs — e.g. 12:32:53 next to 12:32:56 PM.

Root cause

FileActivity.to_dict() called get_time_format() — which re-reads plexcache_settings.json from disk — once per row. The web settings writer rewrote that file non-atomically (open(..., 'w') truncates it to zero bytes before writing). When a settings write overlapped a dashboard render, one row's read could land in the truncated-file window, raise JSONDecodeError, and fall back to the 24h default. At the noon hour the 24h string (12:32:53) is identical to the 12h one apart from the missing PM, so it looked like one row had simply lost its suffix.

Fix

• FileActivity.to_dict() accepts an explicit time_format; the activity render path reads the format once and passes it to every row, so a render is always internally consistent (all rows share one format).
• The settings writer now writes atomically (write-temp-then-os.replace) via the shared save_json_atomically() helper, so concurrent readers never observe a partial/empty settings file. This protects every settings reader, not just the activity feed.
• save_json_atomically() returns a bool so the settings writer keeps its success/failure contract.

Testing

• Added tests covering to_dict() honoring an explicit time_format (and not re-reading settings), and save_json_atomically() reporting success/failure.
• Full suite passes.

Manual verification

1. Open the dashboard's Recent Activity feed.
2. Trigger a run that writes activity while saving a settings change around the same time (the overlap that previously dropped the suffix).
3. Confirm every row within a run shows a consistent time format with its AM/PM suffix.