Targeted single-app renovate: redeploy one app, not a whole target

[ineedjet]

Context

Every deploy trigger today (release, and the cron/manual ones proposed in
#120) operates at target granularity — "redeploy this target's whole
apps set." There's a real, narrower case that doesn't fit that shape: an
app maintained/published elsewhere (the user's own service repo, or any
consumer repo whose app reaches a target via app_refs) just published a
new image version and wants to say "renovate just this one app, wherever
it's actually deployed" — without waiting for the nightly drift-catch
(#120) or triggering a full target-wide redeploy that touches every other
app on that host too.

The input dimension here is an app name, not a target name — the
opposite of every other trigger. A given app can be deployed to more than
one target; this needs to find all of them, not just one.

Proposal (not fully designed — the "how" is open)

• New trigger surface: most likely repository_dispatch (the app's own
  repo, potentially outside this org, notifies flightdeck/the target's
  consumer repo that a new image was published) and/or workflow_call (if
  the caller already lives in a workflow with direct access to invoke this
  one).
• New lookup step: given an app name, determine which target(s) currently
  include it in their apps mapping (targets/*.yml) — no reverse index
  like this exists today; load-yaml-matrix just dumps target manifests
  as-is, it doesn't index by app. This is new logic, not a reuse of
  something that already exists.
• For each matching target, build a filtered apps JSON containing only
  that one app's entry (name + its own env_refs) instead of the target's
  full apps set, then call the same deploy-shared.yml/deploy/deploy.py
  machinery with that narrowed input and the target's hosts/credentials
  — same push-based deploy, just scoped to one app instead of everything
  the target runs.

Open questions

• Where does the app-name -> target(s) lookup live? A new composite
  action (mirroring load-yaml-matrix's shape), or logic inside
  deploy/deploy.py itself?
• Does the caller specify a release ref for the one app's new image/env,
  or does this just re-trigger normal ref resolution (@latest) scoped to
  that app?
• Auth story for repository_dispatch coming from outside this org's
  trust boundary, if that's the real source.

Related

#120 (the release/cron/manual unification this is explicitly not part
of — different impact-area shape, not just a different trigger).

[ineedjet]

Superseded by #168. The deploy-based proposal no longer matches the separate active-release renovate process introduced in #162 and released in v1.0.0.