feat(server): deploy the API to Serverpod Cloud with health version and CORS gate

[TOMOKI977]

Refs #31

Stacked on #114 (Serverpod 4 upgrade). Review and merge #114 first; this PR will then be retargeted to main. Stacked PRs do not run CI, so CI runs once it targets main.

Summary

Server side of #31: the API is live on Serverpod Cloud at https://puls3-hub-on-stellar.api.serverpod.space/.

• Health reports the deployed commit. /health/check returns version from the pubspec plus PULS3_GIT_SHA. A pre-deploy script (tool/set_deploy_sha.dart, run by scloud deploy through scloud.yaml) sets that variable to the deployed short SHA, with -dirty added when tracked files have uncommitted changes.
• CORS origin gate. Browser callers are restricted to PULS3_ALLOWED_ORIGINS. Loopback origins are allowed only in the development run mode, so the deployed server rejects localhost.
• Serverpod Cloud project config. scloud.yaml is linked to puls3-hub-on-stellar, and .scloudignore keeps .env, passwords.yaml and tests out of the upload.
• README "Deploy to Serverpod Cloud". It gives one linear first-deploy path, then redeploy, verify and failure handling, plus the public API URL.

Acceptance criteria

• The public app URL opens and the full demo flow works on testnet (GIF). Not in this PR: the Flutter web deploy to Cloudflare Pages is still pending.
• The health endpoint on the public server returns the deployed version (1.0.0+b88cdaf, below).
• A teammate who did not do the first deploy redeploys by following the README. Needs a teammate: the redeploy steps are in puls3_server/README.md.
• No secret appears in the repo or in the upload. scloud deploy --wet-run --show-files lists .env and config/passwords.yaml as ignored, and the Cloud-managed passwords are generated by the platform.
• Both URLs are in the README. The API URL is in puls3_server/README.md; the app URL comes with the Pages deploy.

Deliverable 6 (the indexer/tracker running on the deployed server) is not enabled: PULS3_TRACKER_ENABLED is left unset until #96.

Verification evidence

$ scloud deploy
(1/1) dart run tool/set_deploy_sha.dart
Setting PULS3_GIT_SHA=b88cdaf
✓ Upload successful.        (8.2s)
✓ Cloud build successful.   (142.1s)
✓ Rollout successful. 🚀    (52.0s)

$ api=https://puls3-hub-on-stellar.api.serverpod.space
$ curl -s -X POST -d '{}' $api/health/check
{"__className__":"BackendHealth","version":"1.0.0+b88cdaf"}
https://puls3-4lw.pages.dev -> 200
https://evil.example.com    -> 403
http://localhost:3000       -> 403

$ scloud log
INFO | Allowed browser origins: [https://puls3-4lw.pages.dev] (loopback not allowed, run mode production)
INFO | applyMigrations: true
INFO | Applied database migration:

$ scloud deploy --wet-run --show-files
│  │  ├─ passwords.yaml     (ignored)
│  ├─ .env                  (ignored)

$ cd puls3_server && dart analyze --fatal-infos && dart test test/unit
No issues found!
00:40 +285: All tests passed!

Notes for reviewers

• The Cloud load balancer answers 411 to a POST without Content-Length, so every verify curl in the README sends -d '{}'.
• Cloud variables set: SERVERPOD_APPLY_MIGRATIONS=true and PULS3_ALLOWED_ORIGINS=https://puls3-4lw.pages.dev. PULS3_GIT_SHA is set by the pre-deploy script. PULS3_STELLAR_* use the testnet defaults.
• After chore(infra): testnet configuration and secrets management #106 merges, PULS3_ALLOWED_ORIGINS and PULS3_GIT_SHA should be added to .env.example and docs/infra/secrets.md (follow-up).
• On Windows Git Bash, scloud must be run as scloud.bat or through cmd //c "scloud ..."; the README notes this.

[cloudflare-workers-and-pages]

Deploying puls3 with    Cloudflare Pages

Latest commit:	2bf134c
Status:	✅  Deploy successful!
Preview URL:	https://f16545f0.puls3-4lw.pages.dev
Branch Preview URL:	https://chore-31-serverpod-cloud-dep.puls3-4lw.pages.dev

View logs

[TOMOKI977]

Added in 011090b: when the Pages project sets PULS3_API_URL, scripts/cloudflare-pages-build.sh passes it as --dart-define. PULS3_API_URL=https://puls3-hub-on-stellar.api.serverpod.space/ is now set for both Pages environments (preview and production). The app reads that define once #106 merges; until then the build ignores it.

[moises-cisneros]

Tested locally on Flutter 3.44.4 (Dart 3.12.2, same as CI): dart analyze --fatal-infos is clean, 325 unit tests pass, and scripts/tests/cloudflare-pages-build.test.sh passes 7/7. I also probed the live API: /health/check returns 1.0.0+b88cdaf, the Pages origin gets 200, evil.example.com and localhost:3000 get 403.

Before merging

• #114 is already merged, but this PR still targets chore/110-serverpod-4-upgrade. Please retarget it to main so the full CI runs.

Minor observations (non-blocking)

1. set_deploy_sha.dart uses --untracked-files=no, so an untracked file that is not in .scloudignore is uploaded while the health version still reports a clean SHA.
2. PULS3_GIT_SHA is set before the upload. If the upload or build fails, the variable already holds the new SHA while the old build keeps running.
3. An OPTIONS preflight from a disallowed origin gets access-control-allow-origin: * from Serverpod core. The real request is still rejected with 403, so it is not exploitable, but the header is misleading. The doc comment on originGate already explains why.

The open acceptance criteria (app URL, Pages deploy, redeploy by a teammate) are acknowledged in the description.