feat: add ResourcePolicyClient for resource-based policy management

[Hweinstock]

Issue #, if available: N/A

Description of changes:

Problem

The SDK has no support for resource-based policies, which allow customers to control which principals can invoke and manage their Agent Runtime, Endpoint, and Gateway resources. This is useful for fine-grained cross-account access and OAuth authentication scenarios. Without SDK support, users must drop to raw boto3 calls.

Solution

Added ResourcePolicyClient in src/bedrock_agentcore/services/resource_policy.py — a thin wrapper around the 3 control plane APIs, following the existing IdentityClient pattern:

• put_resource_policy(resource_arn, policy) — create/update (accepts dict or JSON str)
• get_resource_policy(resource_arn) — get
• delete_resource_policy(resource_arn) — delete

Alternative Solutions

Direct passthrough to boto on client

• Pros: minimal code and logic to maintain.
• Cons: provides little value over using boto directly. Ex. no serialization/deserialization, difficult to extend in future.

Private Class Consumed by primitivates

• Pros: limits the number of classes we expose.
• Cons: Requires manually wiring up resource based policies into each primitive we want to support it.

Testing

• unit tests.
• integ tests: Verifies e2e behavior. Setup additional RESOURCE_POLICY_TEST_ARN and
  RESOURCE_POLICY_TEST_PRINCIPAL secrets.(ran against my dev account).

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (main@62fdc9a). Learn more about missing BASE report.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #328   +/-   ##
=======================================
  Coverage        ?   90.90%           
=======================================
  Files           ?       43           
  Lines           ?     4068           
  Branches        ?      624           
=======================================
  Hits            ?     3698           
  Misses          ?      203           
  Partials        ?      167           

Flag	Coverage Δ
unittests	90.90% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jariy17]

Managing an agent runtime requires two clients: the existing runtime client and a resource policy client. Customers who need to attach resource policies to a runtime will need this additional client.

[Hweinstock]

This is the tradeoff with this approach. If we hide the resource policy functionality behind other clients, the customers can manage an agent runtime with a single client, but we are responsible for wiring that up each time we want to add support for a new primitive or agentcore resource.

Alternatively, if we create a separate class the customer will need separate clients for the mentioned flow, but it allows for a more extendable and flexible design that doesn't require explicitly wiring up each consumer.

[jariy17]

I understand why having a separate client. Thank you for weighing both options. I'm fine with merging this client.

[Hweinstock]

rebase onto integ test changes.