fix(auth): master does not build — restore the #866 SAML handler (#881)

[alex-dembele]

Closes #881

master does not build. Merge e86df5cd resolved the #866/#803 conflict in saml2_handler.go by keeping #866's imports and the old, unsigned SAML2ACS body from #803. internal/handler didn't compile, so none of its tests were running.

This PR restores the file exactly as #866 left it (git show 069b3db8:backend/internal/handler/saml2_handler.go): both SAML entry points refuse every request. #803's SSO session code lives in other files and is untouched.

Don't "fix" this by adding the missing imports instead. That would put the ACS that accepts unsigned assertions back into service.

Verification

• On master 14f26e8e: go build ./... → 11 errors in saml2_handler.go (undefined: base64, xml, domain, …).
• On this branch: go build ./... && go vet ./... && go test ./... -race → BUILD_OK · VET_OK · TEST_OK, 80 packages ok, 0 FAIL.
• TestSAML2ACS_RefusesAWellFormedSuccessResponse, TestSAML2ACS_RefusesAnEmptyPost, TestSAML2InitiateLogin_RedirectsToTheLoginScreen, TestIssueSSOSession_SAMLExitSetsCookiesAndLandsHome, TestIssueSSOSession_SAMLExitFailureRedirectsToLogin → PASS.

Honest remainders

• The master CI doesn't seem to run on these merges (the latest master runs listed are for docs(roadmap): record what W1-05 delivered and what still blocks it (#235) #601), which is how a build break got through. Not investigated here.
• provisionSAML2User and applyGroupRoleMapping go away with the old body, as they did in security(auth): SAML endpoints refuse every request until assertions are verified #866.