feat: resolve dependencies on the remaining conversation mint sites + e2e suite

[serguei-gorokhov]

Applicable issues

• fixes Complete mint-site coverage on conversation APIs and land whole-branch review hardening #1935
• Parent epic: App resource dependencies — scoped access for applications to user resources #1930

Description of changes

This story deliberately folds two halves into one PR — the mixed diff is intentional (the whole-branch review hardening commit is chronologically adjacent to the mint-site commit); reviewers should assess both.

Half 1 — mint-site coverage on the conversation APIs (ad900889). ResolveResourceDependenciesFn now runs in the same chain position on the Anthropic Messages (MessagesBaseController.prepareUpstreamRoute) and Responses (ResponsesController.handleRequestBody) entry points, completing the v1 conversation mint-site coverage (route/feature/deploy sites remain a documented v1 limitation — an app invoked through those surfaces gets no dependency grants in v1). ResourceDependencyApiTest covers the v1 checklist as test cases: the consented flow, required-without-consent failing the call explicitly, optional-without-consent degrading silently, withdrawal stopping the run immediately, declaration change invalidating the grant (content binding), public-target grants following the originating user's own reach exactly, and audit events carrying app, targets, user and trace id (the grant line also carries access types).

Half 2 — whole-branch review hardening (2a40b3f6). Three real defects and a defense-in-depth gap, all in the composed behavior:

• Root-call-only guard semantics. The timing guard threw IllegalStateException on every hop that arrives with a per-request key — the normal state for an interceptor's final call back to a declaring app (breaking even the root user request) and for every chained call into one (400/500 on all three interfaces). Resolution is now honestly root-call-only: hops under a per-request key are skipped — callable, just without grants — because the originating user's reach is not evaluable under a key context (buildUserBucket flips to the parent app's bucket). Chained composition is recorded as phase-2 machinery.
• Internal-type ban. The placeholder type segment now enforces the validator's PERSONAL_TYPED_ROOTS vocabulary (constant made public, shared): ResourceTypes.of() maps internal engine types, so a current-user/credentials/ declaration from a config-file or admin-authored app could otherwise resolve into the user's secret-bearing blobs.
• Union grants. Two records sharing a target combine rights instead of overwriting each other; malformed concrete paths raise RuntimeException shapes that are now caught (unresolvable, never a crash); target permission lookups are batched into one rule-chain walk; consent is checked before any resolution work; the audit's access-type join tolerates null elements. The perRequestReceivers[app] half of the bake — which never propagated on plain chained calls and served no reachable flow — is removed; the grant lives solely in the key's own shared map.

New e2e: a chained call into a declaring app stays callable without receiving grants (the case the old guard broke).

Behavior changes flagged for review

• Required-dependency hard-fail on chained hops is NOT here (that arrives with the chained-resolution PR later in the stack) — in this PR, hops under a per-request key are skipped, never failed.
• Internal engine types (credentials, keys, …) are no longer resolvable via the placeholder, whoever authored the app.
• Records sharing a target now union their grants (previously last-write-wins overwrite).

Checklist

• Title of the pull request follows Conventional Commits specification

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

🤖 Generated with Claude Code