## Why

The platform currently uses in-memory repositories and in-memory log buffers, so users, sessions, jobs, server state, artifacts, and logs disappear when the platform process restarts. Hundreds or thousands of game servers also make row-per-log-line relational storage a poor default: platform metadata needs a durable database, while log bodies need append-friendly segmented storage with bounded cursor reads.

## What Changes

- Add configurable durable platform storage so the default local platform process no longer depends on volatile in-memory repositories.
- Add a local file-backed metadata store for immediate durable operation without external database credentials.
- Add a segmented log body store that persists log entries by stream and segment on disk, keeping log query semantics and duplicate detection intact.
- Update platform startup configuration to choose memory or durable local storage with explicit data/log paths.
- Document that MySQL/PostgreSQL-style databases are appropriate for platform metadata and log indexes, while high-volume log bodies should use segmented object/file storage or a purpose-built log backend such as ClickHouse/Loki/OpenSearch in later changes.

## Capabilities

### New Capabilities
- `durable-platform-storage`: Platform metadata and log bodies survive process restarts through configurable durable storage backends.

### Modified Capabilities
- None.

## Impact

- Affected backend areas: `platform/config`, `platform/repo`, `platform/service`, `platform/api`, `platform/cmd/platform`, `platform/protocol`.
- No frontend page changes.
- No external paid services, real database credentials, or network downloads are required for this implementation.
- Future MySQL or analytics log backends can be added behind the new storage boundaries without exposing raw host paths, credentials, or direct sockets to plugins or the frontend.