Deploy to Azure and AWS buttons that run BaryoVM with the barako stack recipe

**Updated 14 September 2026, after D23 (#800).** The buttons stay, but they run BaryoVM instead of shipping separate ARM, Bicep or CloudFormation templates. A **Deploy to Azure** or **Deploy to AWS** link opens a page from `baryovm serve` (BaryoDev/BaryoVM#15) or runs the setup-baryovm GitHub Action (BaryoDev/BaryoVM#83) with the barako stack recipe (BaryoDev/BaryoVM#87) against Azure Container Apps or AWS App Runner (BaryoDev/BaryoVM#81, #82). One engine and one recipe, so a café deployed by button behaves the same as one poured from the CLI. The prerequisites below (multi-arch images, a managed database choice, no default credentials) still hold.

---

Split out of #352, which covers two jobs of very different size. This is the cheap half, and under an adoption-first plan it is one of the highest-return items on the board.

#352 keeps the marketplace listings (Route B): seller registration, tax and banking details, listing review, weeks of work. That waits.

## What this is

A public ARM or Bicep template gives a **Deploy to Azure** button. A CloudFormation template gives the AWS quick-launch equivalent. Both are a link in the README that opens the cloud's own deployment form with the parameters already filled in.

No Partner Center account, no AWS seller registration, no listing review, no paperwork. Days, not weeks.

It supports exactly the claim already being made, which is that you can run this on your own cloud without reading a compose file first. `.agent/workflows/deploy-fly-io.md` is the existing pattern to extend.

## Why this milestone

It is not a one-way door, so it must not hold 4.0.0. It is also the shortest path from somebody reading the README to somebody running an instance, which is the thing that has to happen before hosting, support or a module ecosystem mean anything.

## What has to be true first

- **#394**, the versioned image tags are amd64 only. Graviton and Ampere are the cheapest compute on both clouds. A launch button that deploys onto the default cheap instance type and fails is worse than no button. Already in 4.0.0.
- **A 4.0.0 tag exists.** The template pins an image tag, and there is no published 4.0 image to pin.
- **A managed database choice.** The compose stack runs Postgres as a container on a local volume, which is right for a laptop and wrong for a cloud template. The application takes a connection string and needs no change; the template has to offer RDS or Azure Database for PostgreSQL, and the docs have to say which is supported.

## What the compose file already gets right

`quickstart/docker-compose.yml` uses `${DB_PASSWORD:?set DB_PASSWORD in .env}` rather than a default, for the database, the JWT key and the initial admin password. It refuses to start rather than shipping known credentials. A generated-secret template has to inherit that, not undo it for the sake of a smoother click.

## Done when

- A Deploy to Azure button and an AWS quick-launch link are in the README and both produce a running instance.
- Secrets are generated by the template, never defaulted.
- The instance comes up on arm64.
- The docs say what the deployed thing costs to run, roughly, because the first question after "it worked" is that one.

Start with .agent/workflows/deploy-fly-io.md and quickstart/docker-compose.yml, then review the baryovm serve and setup-baryovm GitHub Action paths named in the issue. Confirm the 4.0.0 image, managed PostgreSQL choice, arm64 support, and secret behavior before implementing the Azure Container Apps and AWS App Runner deployment links. Done means both README links produce running instances and document approximate cost.

Written by the indexing model from the issue text.