feat(superposition): Add get resolved config explanation proxy support

[NISHANTH1221]

Type of Change

• Bugfix
• New feature
• Enhancement
• Refactoring
• Dependency updates
• Documentation
• CI/CD

Description

Add GetResolvedConfigExplanation superposition proxy support in hyperswitch.

Additional Changes

• This PR modifies the API contract
• This PR modifies the database schema
• This PR modifies application configuration/environment variables

Motivation and Context

How did you test it?

Follow steps in #12203

Checklist

• I formatted the code cargo +nightly fmt --all
• I addressed lints thrown by cargo clippy
• I reviewed the submitted code
• I added unit tests for my changes where possible

[semanticdiff-com]

Review changes with  

Changed Files

File	Status
crates/router/src/routes/superposition_proxy.rs	54% smaller
crates/router/src/routes/lock_utils.rs	25% smaller
crates/router/src/core/superposition_proxy.rs	18% smaller
crates/router/src/routes/app.rs	15% smaller
crates/external_services/src/superposition.rs	1% smaller
crates/api_models/src/superposition_proxy.rs	0% smaller
crates/router_env/src/logger/types.rs	0% smaller

[XyneSpaces]

🔍 [nit] New SuperpositionResolveConfigExplanation route handler uses httpclient directly without connection pooling configuration shown in the diff.

Verify the ExternalHttpClient used for superposition calls has appropriate timeout and retry settings to prevent cascading failures if superposition service degrades.

[XyneSpaces]

Code Review: Superposition Config Explanation Proxy

Findings

[should-fix] In crates/router/src/core/superposition_proxy.rs, the new handle_superposition_proxy_flow function (renamed from handle_proxy_flow) should have #[instrument(skip_all, fields(...))] attribute added since it's an async function in a hot path. The existing calls don't appear to have tracing instrumentation.

[blocking] In crates/router/src/routes/superposition_proxy.rs, the resolve_config_explanation handler at line ~245 creates a closure that captures request by cloning it. Since ResolveConfigExplanationRequest contains potentially sensitive context data (configuration dimensions), ensure this doesn't get logged inadvertently via #[instrument] on the route handler.

[nit] The ResolveExplanationEntry struct in api_models/src/superposition_proxy.rs uses serde_json::Value for condition, value_before, and value_after. This is acceptable for a proxy response type, but document that these are opaque Superposition-specific values.

[should-fix] In resolve_config_explanation_to_response function, consider adding error context if doc_map_to_json or document_to_value conversions fail — currently the error propagation isn't visible in this diff snippet.

[XyneSpaces]

[should-fix] Missing #[derive(serde::Deserialize)] on ResolveExplanationEntry.

The struct derives Serialize but not Deserialize, preventing round-trip deserialization of the explanation response. Add serde::Deserialize if this type needs to be parsed from JSON elsewhere.

#[derive(Debug, Clone, serde::Serialize, serde::Deserialize)]
pub struct ResolveExplanationEntry {

[XyneSpaces]

[nit] Renaming handle_proxy_flow → handle_superposition_proxy_flow is a breaking change for any internal callers.

The PR updates all existing call sites, which is good. However, the rename itself is purely cosmetic and increases diff noise. Consider whether the disambiguation is worth the churn, or if the original name with module-level clarity (superposition_proxy::handle_flow) suffices.