Improve OIDC handling in RequestClient #106

vercel-py now resolves OIDC from request header context in its shared credential path, which fixes the immediate gap for SDK flows inside Vercel-served requests. What remains is cleanly modeling the full OIDC lifecycle across both deployed usage and local linked-project development.

In deployed preview and production runtimes, OIDC is request-scoped. The active request provides x-vercel-oidc-token, and SDK calls during that request should treat it as authoritative. Today, RequestClient still freezes the bearer token into base headers at construction time, so reused clients or long-lived objects can silently carry a stale token after request context changes. Token discovery now respects request context, which is the improvement, but request-scoped semantics are not yet preserved all the way to send time.

Local development is a bit different. Request-scoped OIDC is typically not available, so the fallback path needs to come from local project metadata, pulled env, cached OIDC state, and refresh logic backed by local auth. The JS package is a useful reference here. Python has pieces of that local story, but they are not yet composed into a complete model alongside the deployed path. The SDK should not silently drift from request-scoped auth into local-style fallback because a token was captured too early, and local dev should not require manually managing VERCEL_OIDC_TOKEN or recreating the production auth flow by hand.