Unify deploy.yml's triggers: release, cron, and manual all reuse one entry point

[ineedjet]

Context

release.yml currently has its own embedded deploy-targets+deploy job
pair (fires automatically once a release publishes), and deploy.yml has
an essentially identical deploy-targets+deploy job pair (fires only on
manual workflow_dispatch). Both independently call the same
deploy-shared.yml — the job logic itself isn't duplicated, but the
"build a target matrix and call deploy-shared.yml" wiring is, in two
separate files.

Separately: there's a real need for a third trigger — a nightly/periodic
"renovate" run that isn't tied to a release at all, just to catch
floating-tag image drift for apps not pinned to an exact tag/digest
(docker compose pull && up -d picks up a new upstream image on its own,
it just needs something to actually run it periodically). This is the
cron idea #100/#118 already floated as Watchtower's replacement, but
there's nowhere for it to live yet.

Proposal

deploy.yml gains all three triggers in one on: block:

• workflow_dispatch (already has this — manual, ad-hoc, supports
  targeting one target via inputs.target)
• schedule (new — nightly cron, defaults to target: all since the
  point is catching drift everywhere, not a targeted redeploy)
• workflow_call (new — makes the whole file callable as a reusable
  workflow)

release.yml's own deploy-targets+deploy jobs are replaced with a
single job: uses: $/.github/workflows/deploy.yml (workflow_call),
passing target: all. Needs verifying precisely at implementation time:
deploy.yml's actions/checkout step has no explicit ref today (so it
checks out whatever SHA triggered the run) — when called via
workflow_call from release.yml, confirm this correctly resolves to the
released commit either by default (inherited run context) or by adding an
explicit ref input threaded through from release.yml's
needs.release.outputs.tag_name, matching this repo's preference for
explicit wiring over implicit inheritance.

Net result: one file owns "deploy a target (or all targets)," with three
independent ways to trigger it, no duplicated job definitions.

Related

#100 / #118 (the cron-replaces-Watchtower idea this makes concrete).