docs(dotnet/token-refresh): flag discovery-caching gap in production notes

Code review caught that RefreshTokensAsync fetches the discovery
document on every refresh call. For a teaching sample that's fine,
but readers copying the pattern to prod would eat an extra round-trip
per refresh. README production-notes now says so.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: ksroda-sa

samples/dotnet/token-refresh/README.md

@@ -44,3 +44,4 @@ Six tests covering `/` unauth, `/` authenticated, `/login` challenge, `/refresh`
 - **CSRF protection:** `POST /refresh` is not CSRF-protected. For production, enable ASP.NET Core antiforgery middleware, switch cookies to `SameSite=Strict`, or use a double-submit cookie pattern.
 - **Concurrent refreshes:** two requests may race on the refresh token with rotation-enforcing IdPs. Production apps should serialize refresh per session (e.g. via `SemaphoreSlim` keyed by session id).
 - **Auto-refresh scope:** `OnValidatePrincipal` fires for every authenticated request including static assets and health checks. In production, consider wrapping the refresh logic so it only runs for routes that actually use the access token.
+- **Discovery caching:** for readability, `RefreshTokensAsync` fetches the OpenID discovery document on every call. Each refreshed access token costs an extra network round-trip. Production apps should cache discovery for the lifetime of the process (or reuse the `ConfigurationManager<OpenIdConnectConfiguration>` that the OIDC middleware already maintains).