enhance: strip user session information before forwarding

[LaurenceJJones]

Community Contribution License Agreement

By creating this pull request, I grant the project maintainers an unlimited,
perpetual license to use, modify, and redistribute these contributions under any terms they
choose, including both the AGPLv3 and the Fossorial Commercial license terms. I
represent that I have the right to grant this license for all contributed content.

Description

This PR introduces upstream request sanitization so Badger can consume session/auth data for validation while preventing those sensitive values from being forwarded to backend services.

Why

Badger should validate session material but not forward that sensitive session/auth context to downstream apps.

This change ensures:

1. Least-privilege forwarding:
   Downstream receive identity context, not raw session secrets.

2. Reduced leakage risk:
   Session tokens are removed from URL query, headers, and cookies before proxying (and logs/observability systems downstream are less likely to capture secrets).

3. Consistent sanitization:
   Stripping is applied in one place for all supported transport paths (query params, headers, cookies).

4. Traefik plugin compatibility:
   Implementation avoids APIs unavailable in Yaegi, preventing plugin load failures while keeping sanitization behavior intact.

What changed

1. Strip session cookies:

• Removes only cookies matching userSessionCookieName*
• Preserves all other cookies untouched
• Handles multiple Cookie headers
• Uses Yaegi-compatible parsing logic (no net/http.ParseCookie)

2. Strip session query params:

• Removes resourceSessionRequestParam
• Removes configured access-token query param (when set)

3. Strip token headers:

• Removes P-Access-Token-Id
• Removes P-Access-Token

4. Keep forwarded identity headers:

• Continues to pass Remote-User, Remote-Email, Remote-Name, Remote-Role when session is valid

Behavior notes

• Request cookies only carry name=value; Set-Cookie attributes (Path/Domain/SameSite/etc.) are response-side and are not modified here.
• This logic avoids mutating unrelated cookies beyond normal header re-join formatting.

How to test?

Personally I setup a whoami container behind pangolin SSO and used an invite link, use a preauthenticated browser to access the resource, what was echoed to the page was all sensitive information being removed before forwarded to backend service but headers for user auth like remote-user are preserved.