Add a Fly deploy provider so publish works on fly targets (#585)

* Add a Fly deploy provider so publish works on fly targets

DEPLOY_PROVIDER=fly is documented and gates FLY_DEPLOY_API_TOKEN in the
secret schema, but provider selection only knew "aws" and "docker", so
"fly" silently fell back to the docker provider. A fly-target core runs
in a Fly Machine with no docker binary and no daemon, so every publish
failed with "spawn docker ENOENT".

The provider drives the Fly Machines API directly. apply() packs the
version snapshot as a gzipped tar delivered through the machine config
files field, creates a per-deployment app under FLY_DEPLOY_APP_PREFIX in
FLY_ORG, replaces any existing machines before creating the new one so
<app>.internal never round-robins across versions, boots
FLY_DEPLOY_BASE_IMAGE with an init that unpacks and executes the version
entrypoint, waits for the machine to start and the port to accept, and
returns a private 6PN endpoint. No public IPs are ever allocated;
deployed apps stay reachable only through core's authenticated proxy.
destroy() deletes the app, tolerating 404. Failure messages carry the
machine's exit event (exit code, OOM) since the Machines API exposes no
process output; the optional logs() capability is left unimplemented for
the same reason.

Oversized bundles fail fast with the packed size before any API call,
machine-config files delivery having no room for large payloads. App
creation treats name-taken responses as success so re-publishing is
idempotent. The API client, port dialing, and timeouts are injectable;
the tests run the full apply/destroy flow against a fake fetch with no
network.

* Harden Fly app deployment isolation and rollout

* Make Fly deploy lifecycle recoverable

* Fail closed when Fly cutover target vanishes

* Restore routes after ambiguous Fly cordons

* Fix README formatting

---------

Co-authored-by: kai-jmi <kai-jmi@users.noreply.github.com>
Co-authored-by: Josh France <12610835+16francej@users.noreply.github.com>