Expose UpstreamFilter through authserver.New facade

[tgrunnagle]

Summary

WithUpstreamFilter (added in #5725) let a caller narrow the upstream authorization chain, but it was only reachable through the low-level handlers.NewHandler constructor. The public pkg/authserver.New facade and its Config had no way to inject an UpstreamFilter, so any caller embedding the auth server through the facade could not install a filter at all.

This adds an UpstreamFilter field to authserver.Config and threads it into the handler options assembled in newServer, mirroring how the existing upstream-token refresher is already wired. A nil filter (the default) preserves current behavior of walking every configured upstream, so the change is fully backward-compatible.

Closes #5732

Type of change

• New feature

Test plan

• Unit tests (task test)
• Linting (task lint-fix)

pkg/authserver/integration_test.go gains TestIntegration_MultiUpstreamChain_ConfigUpstreamFilter, which drives a two-upstream chain end-to-end through authserver.New with a Config.UpstreamFilter that drops the second provider, and asserts the handler redirects straight to the client after the first callback instead of continuing on to provider-2. The pre-existing TestIntegration_MultiUpstreamSequentialChain is unmodified and now implicitly covers the nil-filter (no-behavior-change) path through the same facade wiring. The full pkg/authserver suite passes, and gofmt/lint are clean on all three changed files.

Does this introduce a user-facing change?

No end-user or CLI-facing change. It adds a new optional field, Config.UpstreamFilter, to the public pkg/authserver.Config struct for Go callers that embed the auth server; existing callers are unaffected since a nil filter preserves today's behavior.

Special notes for reviewers

• Follow-up to Filter upstream auth chain via callback hook #5725, which introduced handlers.UpstreamFilter / WithUpstreamFilter at the handler level but left them unreachable from the authserver.New facade.
• server_impl.go gains a small buildHandlerOptions helper so the handlers.Option slice is assembled once, appending the filter option only when cfg.UpstreamFilter is non-nil.
• The new integration test lives in integration_test.go rather than next to handler_chain_test.go as the issue suggested, since it specifically exercises the Config → authserver.New → handlers.NewHandler wiring; the lower-level chain-narrowing logic (computeChain) is already unit-tested in handler_chain_test.go.
• No in-repo caller currently sets Config.UpstreamFilter — wiring an actual filter policy for a real caller is out of scope for this issue and left as follow-up work.

Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.74%. Comparing base (609c0ad) to head (3451b89).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5733      +/-   ##
==========================================
+ Coverage   70.68%   70.74%   +0.05%     
==========================================
  Files         682      682              
  Lines       68949    68958       +9     
==========================================
+ Hits        48736    48783      +47     
+ Misses      16665    16619      -46     
- Partials     3548     3556       +8     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tgrunnagle]

Multi-Agent Consensus Review

Agents consulted: architecture-api-design, security, test-coverage, general-code-quality

Consensus Summary

#	Finding	Consensus	Severity	Action
1	Config.Validate() doesn't guard against UpstreamFilter set with fewer than 2 upstreams	9/10	MEDIUM	Fix
2	withUpstreamFilter test option is silently ignored by 4 of 5 setup helpers	8/10	MEDIUM	Fix
3	Typed-nil interface value can defeat the nil-filter fast path	7/10	LOW	Fix
4	New test duplicates leg-1 HTTP flow boilerplate	7/10	LOW	Fix
5	Doc comment overstates a "second failure signal" that can't occur	7/10	LOW	Fix

Overall

This threads the UpstreamFilter hook added in #5725 through the public authserver.Config/authserver.New facade, mirroring the existing UpstreamTokenRefresher wiring pattern exactly. The approach is sound: buildHandlerOptions preserves nil-filter backward compatibility byte-for-byte, there's no import cycle, and the new integration test proves the wiring with two independent signals (an HTTP status code and a storage-level assertion) rather than a shallow check.

The findings below are validation-gap and test-hygiene polish, not correctness defects. The one worth prioritizing is the Config.Validate() gap: a caller can set UpstreamFilter with a single configured upstream and get a silent no-op instead of a startup error, which cuts against this repo's own "fail loudly on invalid input" convention. The test-option no-op (a withUpstreamFilter option only 1 of 5 setup helpers actually honors) is a real footgun for future test authors, even though it doesn't touch production code. The rest are comment-accuracy and DRY nits in the new test.

Nothing here should block merge.

---

Generated with Claude Code