Add regression acceptance test for auth context propagation through full ListCapabilities → Close() path

[yrobla]

Context

Raised as a suggestion in #4613, which fixed a subtle bug where mcp-go creates a fresh context.Background() internally, causing auth context to be lost at teardown.

The unit tests on identityPropagatingRoundTripper are thorough and verify the transport layer in isolation. However, this class of bug (context loss at an internal boundary) is subtle enough that it could easily regress if a future change introduces another context boundary — in mcp-go, in a middleware layer, or anywhere between the caller and the backend.

Suggestion

Add a regression acceptance test that exercises the full ListCapabilities → Close() path against a real (or test-double) backend with auth strategies enabled, and asserts no auth errors are logged or returned during teardown.

A higher-level test would catch context loss from any layer, not just Close(), making the fix more durable over time.

Acceptance Criteria

• A test exercises the full ListCapabilities → Close() path end-to-end
• The test uses a real or test-double backend with auth strategies enabled
• The test asserts that no auth errors occur during teardown
• The test would fail if the context.Background() regression (Fix health-check close failing auth in vMCP BackendClient #4613) were reintroduced

References

• PR Fix health-check close failing auth in vMCP BackendClient #4613 (original fix)