feat: add allowedTools and tools overrides to harness invocation API

[avi-alpert]

Description

Add allowedTools and tools fields to HarnessInvocationOverrides, enabling the Web UI to pass tool configuration through to harness invocations.

Also replaces hand-rolled HarnessModelOverride and HarnessToolOverride types in api-types.ts with imports of HarnessModelConfiguration and HarnessTool from agentcore-harness, eliminating type duplication and letting the compiler enforce compatibility between the Web UI API layer and the harness SDK.

Backwards compatible — the new fields are optional, so existing frontends continue to work without changes.

Changes

• api-types.ts: Import HarnessModelConfiguration and HarnessTool from agentcore-harness; remove duplicated HarnessModelOverride and HarnessToolOverride interfaces; add allowedTools and tools to HarnessInvocationOverrides
• harness-utils.ts: Wire allowedTools and tools through buildInvokeOptions; drop unnecessary as HarnessModelConfiguration cast
• harness-utils.test.ts (new): Unit tests covering all override fields to detect API shape drift

Type of Change

• New feature

Testing

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• My changes generate no new warnings

---

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

[agentcore-cli-automation]

Reviewed — looks good to merge.

• The new allowedTools/tools overrides flow cleanly through buildInvokeOptions, so both handleHarnessInvocation and handleHarnessToolResponse pick them up automatically.
• Swapping the hand-rolled HarnessModelOverride for the SDK's HarnessModelConfiguration/HarnessTool is a nice cleanup; confirmed HarnessModelOverride isn't referenced anywhere else in the repo, and the as HarnessModelConfiguration cast is correctly dropped.
• New fields are optional, so existing callers keep working.
• Unit tests cover every override field individually plus the combined case and the no-overrides default — good coverage for detecting future API-shape drift.