Introduce a named request type for the proxy signing path (remove options: any)

## Description

The proxy's request-signing path threads the outbound request as `options: any` through `fetchData → retryFetch → buildFetchOptions` (`packages/graph-explorer-proxy-server/src/app.ts`). Now that signing uses `@smithy/signature-v4`, the aws4/node-fetch shape impedance that once justified `any` is gone, so these should carry a named domain type.

Two related cleanups:

- **Remove `options: any`** on `retryFetch` and `buildFetchOptions`; introduce a named request type (e.g. `{ method: string; headers: Record; body?: string }`) so signing inputs are typed at the boundary. (AGENTS.md: avoid unnecessary `any`; prefer named domain types.)
- **Bundle the data clump**: `(url, options, isIamEnabled, region, serviceType)` travel together into `retryFetch`, `buildFetchOptions`, and `fetchData`. Group them into a single request/context object.

## Notes

- `fetchData`'s param is currently `RequestInit` and spreads `...options`, so the refactor must reconcile the `HeadersInit` vs `Record` shape at that boundary.
- Type/structure only — no functional change intended. Follow-up from the credential-caching / SigV4 signer change.

> [!IMPORTANT]
> Internal only — this issue is maintained by the core team and is not accepting external contributions.

Read packages/graph-explorer-proxy-server/src/app.ts and trace fetchData, retryFetch, and buildFetchOptions. Define the named request/context shape at the signing boundary, reconcile the RequestInit and HeadersInit usage, and confirm the refactor introduces no functional change.

Written by the indexing model from the issue text.