Refactor transcript file handling to use JSON metadata

This commit changes the way transcriptions are stored and accessed.
Instead of using plain text files (`.transcript.txt`), transcriptions
will now be part of a JSON metadata file (`<stem>.json`). This allows
for richer metadata to be stored alongside the transcript, such as
duration, and provides a more robust mechanism for tracking
transcription states.

The changes include:
- Updating documentation and code to reflect the new `.json` file
  extension.
- Modifying file handling logic to read and write JSON metadata.
- Adjusting tests to accommodate the new file format.

server/tests/failed_only_case_empty_oneliner_test.rs

@@ -5,14 +5,14 @@
 //! `compute_oneliner_display` fallback.
 //!
 //! The historical bug path: `.m4a.failed`-only cases were skipped by the
-//! recovery scan (`has_any_transcript` looked for `*.transcript.txt`
-//! only), so `update_oneliner` never ran, so no `oneliner.json` was
-//! written. The UI masked the symptom with its `non_failed_count == 0`
-//! fallback — but a future refactor of that fallback would regress the
-//! case. The fix makes `has_any_transcript` count `.m4a.failed` too, so
-//! `update_oneliner` runs, sees no content transcripts, and settles the
-//! case to `Empty` through the same terminal branch used for silent-only
-//! cases.
+//! recovery scan because `has_any_transcript` only looked for transcript
+//! sidecars and ignored failure markers. `update_oneliner` therefore
+//! never ran, so no `oneliner.json` was written. The UI masked the
+//! symptom with its `non_failed_count == 0` fallback — but a future
+//! refactor of that fallback would regress the case. The fix makes
+//! `has_any_transcript` count `.m4a.failed` too, so `update_oneliner`
+//! runs, sees no content transcripts, and settles the case to `Empty`
+//! through the same terminal branch used for silent-only cases.
 
 mod common;