Use consistent unprivileged MySQL dumps for Server backups

[rmcdaniel]

Change

Corrects the published self-hosted backup example for #236. The dump now uses --single-transaction --quick --no-tablespaces. The guide tells operators to avoid schema changes during the snapshot, inspect dump errors, and restore into an isolated replacement with Server processes stopped and external objects copied before traffic moves.

Evidence

In an isolated stack using published Server 2.4.18 digest sha256:8dcd89f57fbcf3ba6369f23ae815abe6087185602f904105fb67757ab5e5a3ed, pinned MySQL 8.4 digest sha256:679e7e924f38a3cbb62a3d7df32924b83f7321a602d3f9f967c01b3df18495d6, Redis 7.2 and published Python SDK 2.0.0:

• All 49 Server tables in this fixture were InnoDB. The existing documented mysqldump command emitted PROCESS privilege error text but returned status 0 and a dump footer. This makes exit status alone a weak backup check.
• The revised command completed without that error. Its SQL imported into a fresh isolated stack. Three external payload objects (32,872 encoded bytes total) were copied and read back with matching SHA-256 values while the bounded backup hold was active.
• Restored workflow histories and input payloads matched their pre-backup hashes. A pending workflow completed through a newly registered worker with one WorkflowCompleted event. The inclusive manual restore-to-verification wall time was 233 seconds.

The object store in this first drill was an isolated S3 test server. #236 remains open for complete customer-outcome qualification, including a production-like object-store pass and published evidence artifacts. This PR does not claim that full outcome.

MySQL 8.4's mysqldump reference documents the consistent InnoDB snapshot and privilege behavior of these options.

git diff --check passed.