Generator client docs don't cover Docker data persistence (Host docs do)

[johnnymatthews]

The Host client install page has a "Running a persistent host" section explaining how to mount volumes so data survives container recreation. The Generator client install page has no equivalent, and its example command actively guarantees data loss.

What's wrong

Generator install page runs the client with --rm and no volumes

content/run/run-a-generator/install/index.md starts the Generator with --rm and no -v mounts (around line 54). --rm deletes the container on exit, and without volumes the DefraDB database, node identity, and signing keys are gone the moment the container stops. Anyone running this past a quick test loses everything on the first restart.

The troubleshooting section on the same page already references ~/data/defradb ~/data/lens and a chown -R 1001:1001 step, but the install command never creates or mounts those directories. The docs describe a persistent setup in troubleshooting that the install steps never set up. There's also a note telling users to "Restore the original value in your compose file and restart" for a changed keyring secret, but the install page never gives a compose file.

validator-with-geth deployment example has no volumes

content/run/run-a-generator/deployment-examples/validator-with-geth/index.md is framed as a real deployment ("run the Generator client beside your own Geth node") with --restart unless-stopped, but the docker run (around line 41) has no volume mounts. An image update, host reboot, or accidental docker rm wipes the database and identity. The other Generator deployment examples (managed-gcp-node, nginx-with-snapshots, high-throughput-tuning) all use compose files with ~/shinzo-data/defradb:/app/.defra, so this one is the odd one out.

get-started quickstart doesn't flag that data is ephemeral

content/run/get-started/index.md runs both clients with no volumes. That's fine for a quickstart, but there's no callout telling readers the data won't survive a restart or pointing them to the persistent setup on the install pages.

Why we should be explicit

Persistence here isn't generic Docker knowledge. An operator who knows Docker still needs to be told which container paths to mount (/app/.defra/data, /app/.defra/keys, /app/.lens), that the container runs as UID 1001:1001 and host dirs need chown to match, and that the keyring secret has to stay constant across restarts or the identity is unrecoverable.

The Host docs already set this precedent. The Generator docs should match.

Proposed changes

1. Generator install page: drop --rm from the example and add a "Running a persistent Generator" section mirroring the Host's, with the volume mounts and chown 1001:1001 step. This also makes the existing troubleshooting section consistent.
2. validator-with-geth: add volume mounts to the docker run, or switch to a compose file like the other deployment examples.
3. get-started: add a short note after the Generator and Host docker run blocks saying the data is ephemeral, with a link to the install pages for persistent setups.
4. Worth aligning the mount strategy across pages. The Host persistent section mounts .defra/data and .defra/keys separately plus .lens under ~/data/, while the Generator compose examples mount the whole .defra under ~/shinzo-data/ and skip .lens. Check whether the .lens difference is intentional (lens may be Host-only) and pick one base path.