Clarify caddyauth user placeholder semantics after #7685

[steadytao]

Issue Details

Follow-up to #7685.

#7685 changed caddyauth so http.auth.user.* placeholders may be set when an authentication provider returns user information even if authentication is rejected with authed=false.

This fixed the reported error-handler use case but it also changes the effective semantics of http.auth.user.*. Historically, these placeholders have effectively represented a successfully authenticated principal. With the current behaviour on master they may also represent a provider-returned but rejected identity.

This should be resolved before the next release, either by:

1. keeping the new behaviour and documenting it clearly as a behaviour change, or
2. preserving http.auth.user.* for successfully authenticated users only and introducing a separate namespace for rejected-but-identified principals

My preference is the second option likely using a namespace such as http.auth.candidate.* because it avoids blurring the trust semantics of http.auth.user.* while still supporting the use case from #7684.

Assistance Disclosure

AI not used

If AI was used, describe the extent to which it was used.

No response

[steadytao]

@steffenbusch Just mentioning you here in-case you wish to comment. Thank you again.

[steffenbusch]

Glad to see this being addressed before release.

I agree that http.auth.user.* should remain reserved for successfully authenticated principals to preserve its established trust semantics.

On naming, I wonder whether http.auth.candidate.* is the best fit. Since the identity may already have been rejected rather than still being a candidate, http.auth.claimed.* might better reflect that it is an unverified identity claim.