fix(oidc) :: pin the redirect cap on a failed login test

[81reap]

When an OIDC callback fails, SQLPage sends the browser back to the identity provider to try again. The sqlpage_oidc_redirect_count cookie counts those attempts. Once the count reaches MAX_OIDC_REDIRECTS, SQLPage shows the error instead of redirecting again. Without that cap, a misconfigured provider leaves the browser looping between the two.

Adds a test for this case.

[lovasoa]

switching to draft until the pr is ready (including a motivation)

[81reap]

@lovasoa this is it, there's nothing more. the PR title is self descriptive. its just improving gaps in testing that was found by #1396. This would have gone with #1423 but following the ask in #1412 I've broken this out into a separate PR since it doesn't really help #1423

[lovasoa]

If you want to change the codebase, you need at least one or two sentences to explain what you want to do and why. This PR name starts with "fix" and does not even actually fix anything ! It's just tests changes. If you think something needs changing in the tests, you need at least one or two sentences to explain what and why.

[81reap]

ah i see the confusion. as per conventional commits, fix is used to signify a minor version bump which would include updating tests and nothing else. while some specific versions of conventional commits (see Angular) expand this to include test as a prefix I've learned it's bad practice to do that when the base standard doesn't have it

#1402

[lovasoa]

I know human written, coherent PR descriptions for each PR introduce some friction, but this is on purpose. A few years ago, just having spent time on writing the code usually demonstrated a high enough level of effort to prove a given change was important enough, and that someone actually cared and had thought deeply about that particular change. But today, this needs to be demonstrated in a separate channel.

[81reap]

But today, this needs to be demonstrated in a separate channel.

I agree. since this is just changes to unit tests I was under the impression that a passing CI would be that separate independent automated check of my code change.

Alternatively if we want to go back to #1402 to establish new standards to outline the expected separate channels I can def help with that too! I'm just trying to think in the long term of how to avoid these kinds of issues not just with me but others as well :)

but this is on purpose

IMO humans and agents, alike, are susceptible to the path of least resistance which leads to the broken window concept I call out here. This is also why I'm choosing to fix the lower hanging fruit of mutation tests before bigger things like #1385, #1386, and #1387. But a written/established standard (even if there are a limited amount of devs right now) helps raise that minimum bar