Log when a related resource's origin object can't be found

[rose-krone]

Summary

resolveRelatedResourceObjectsInNamespaces silently swallows a NotFound when fetching a
related resource's origin object, on the assumption (per its own comment) that this can only
happen in a narrow List/Get race. It also fires permanently whenever a related resource's
object.template/reference/selector computes a name that never matches a real object — a
config bug, not a race — and in that case every reconcile of the primary object hits it again,
silently, while still reporting success.

This PR threads the *zap.SugaredLogger that's already available at both call sites
(processRelatedResource's own log param, and confirmOriginEmpty's s.log) through
resolveRelatedResourceObjects → resolveRelatedResourceObjectsInNamespaces, and logs the
related resource's identifier plus the computed origin namespace/name when the NotFound is
hit, so a misconfigured related resource is diagnosable from the agent's own logs instead of
only by reading the source.

Found while debugging a cluster-scoped, identityHash-based related resource that never synced
in a real deployment — the actual root cause was a naming-template bug in our own config, but it
took a full day of eliminating hangs/RBAC/permission-claims/network policy to get there, purely
because nothing in the agent's logs, metrics, or events pointed at the actual cause.

What Type of PR Is This?

/kind bug

Release Notes

* The Sync Agent now logs when a related resource's origin-side object can't be found by its
  computed name, instead of silently skipping it

[kcp-ci-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign xrstf for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kcp-ci-bot]

Hi @rose-krone. Thanks for your PR.

I'm waiting for a kcp-dev member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.