fix(federation): report and remove partner-hosted instances correctly

Two bugs on the federated path, both seen on the three-operator test env.

A failed partner deploy left the OEG instance stuck in "instantiating" for 30
minutes, blocking the same app in that zone with a 409. When FM reported the
failure, SRM marked the hand-off target failed but dropped FM's error, so the
completion's instance entry had status failed and no error. The SRM contract
(Sec. C.2) requires one, OEG refused the event as invalid, and only its
reconciler freed the zone. The failed target now keeps FM's error (or a
generic problem when none came) and the instance entry carries it; failed
local instances on that path get the generic problem too. The two replay paths
attached an error only when the whole operation failed, so a failed instance
in a partly completed order also went without one; they now follow the
instance's own status.

Deleting an instance a partner hosts failed before reaching FM: the federated
branch of TerminateServiceUseCase.accept wrote target_service_instance_id =
the instance id, a foreign key to a service_instance row SRM never creates
for partner-hosted instances (ADR-0053, 2026-10-08 amendment). Postgres
refused the insert, RemoveApp was never sent and the release stayed on the
partner. The order now leaves it empty, as a federated deploy order already
does; the hand-off target names the instance. The unit test asserted the old
value because its mock has no foreign keys; a new integration test runs
accept() against Postgres.

The terminate hand-off now records the zone from FM's internal instance
read, so its completion satisfies the zone_id contract and OEG accepts it.
An instance unknown to both SRM and FM fails before starting.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>