fix: config validation hardening and integration polish

- providers.go: validate provider names against ^[a-zA-Z0-9._-]+$ and
  reject reserved names (v1, mcp, a2a) that would shadow gateway routes;
  reject nil ProviderConfig map values at construction instead of
  panicking.
- mcp_a2a.go: apply the same name-pattern and reserved-name validation to
  mcpServers/agents keys, and reject nil TargetConfig/AgentConfig map
  values at construction.
- auth.go: reject nil GroupConfig map values at construction.
- provider_openai_test.go, mcp_a2a_test.go, auth_test.go: table-driven
  constructor-error coverage for the above.
- integration/integration_test.go: point the package doc at
  `make integration-up`/`integration-keep` instead of a bare
  `docker compose up -d --build`, which skips the dynamic.yml.tmpl
  render step and can run against a stale or absent dynamic.yml; add
  max_tokens to the gemini chat request so translate_gemini.go's
  hasMaxTokens=true branch is actually exercised under real Yaegi.
- translate_gemini.go: soften the max_tokens comment's verification claim
  to match what the integration suite actually now exercises.

translate_gemini.go

@@ -368,9 +368,10 @@ func geminiRequestFromOpenAI(req map[string]any) (map[string]any, error) {
 	// v0.16.1 panics interpreting a multi-value assignment mixing a
 	// variable and a literal in one statement on this exact live path (the
 	// same class of bug as sse.go's readSSE dispatch and registry.go's
-	// resolveAgainst — see those files' comments). Verified empirically
-	// under real Traefik (Task 15's integration suite, the gemini chat
-	// completion path).
+	// resolveAgainst — see those files' comments). The hasMaxTokens=true
+	// branch below is exercised by the integration suite's gemini chat
+	// request (integration/integration_test.go, TestUnifiedChatAllProviders,
+	// which sets "max_tokens") under real Traefik + Yaegi.
 	if v, ok := req["max_completion_tokens"]; ok {
 		if n, ok2 := toInt64(v); ok2 {
 			maxTokens = n