fix: handle dot-containing claim names in nested claim resolution

[strobelpierre]

Summary

When --resolve-nested-claims=1 is enabled, getClaimValues() uses explode('.') to split claim paths. This breaks for:

1. URL-based claim names (valid per OIDC Core §5.1.2): https://idp.example.com/claims/groups gets split at hostname dots
2. Object keys with literal dots: {"user.role": "admin"} gets interpreted as nested navigation

Approach: greedy longest-prefix matching

Replace explode('.') with a recursive resolver (resolveNestedClaim()) that:

1. Tries the full remaining path as a literal key first
2. Then tries progressively shorter dot-prefixed segments (longest first)
3. Recurses into the remainder when a prefix matches a nested object/array

This preserves full backward compatibility — existing dot-separated nested paths resolve identically since the algorithm falls through to the same splits.

Examples

Claim path	Token payload	Result
https://idp.example.com/claims/groups	{"https://...groups": ["admin"]}	["admin"]
https://idp.example.com/attrs.role	{"https://...attrs": {"role": "admin"}}	"admin"
https://idp.example.com/attrs.user.role	{"https://...attrs": {"user.role": "admin"}}	"admin"
custom.nickname	{"custom": {"nickname": "alice"}}	"alice" (backward compat)
a.b	{"a.b": "flat", "a": {"b": "nested"}}	"flat" (literal key precedence)

Fixes #1373
Related: #1100

Test plan

• Added 13 data-provider test cases covering: flat keys, nested keys, URL claim names, URL + nested navigation, URL + dotted sub-keys, deep nesting, pipe fallbacks, non-existent paths, empty paths, literal dot key precedence, array payloads
• Added regression test for flat mode (nested resolution disabled)
• CI phpunit pass

[julien-nc]

@strobelpierre Lgtm. Thank you (and Claude 😁)

@andreblanke @dragonpil Can you confirm the backward compatibility is preserved in this PR for all your use cases?

[strobelpierre]

@strobelpierre Lgtm. Thank you (and Claude 😁)

@andreblanke @dragonpil Can you confirm the backward compatibility is preserved in this PR for all your use cases?

Claude and I thank you too, haha 🤝❤️

[julien-nc]

@strobelpierre I don't know what's gonna become the standard but here is my advice: Keep the "generated with AI/whatever you use" footer in PR comments and in issues. This is more honest and has less chances to trigger readers that don't like AI and will immediately detect AI generated content from the style and the length.

[strobelpierre]

@strobelpierre I don't know what's gonna become the standard but here is my advice: Keep the "generated with AI/whatever you use" footer in PR comments and in issues. This is more honest and has less chances to trigger readers that don't like AI and will immediately detect AI generated content from the style and the length.

I completely agree with you, but on another project I had a PR that was fine and added a real feature, and I left the mention claude code that I use to formalize the PR format and also to code. The PR was rejected on the grounds that they don't accept code generated by AI, even though all the tests were fine. There are gatekeepers who automatically reject it.

[andreblanke]

@julien-nc Looks good to me as well. Thanks for the ping.

[julien-nc]

There are gatekeepers who automatically reject it

I hope this does not turn into a war between AI supporters and detractors.
Honestly your PR is readable, tested, commented, scoped. IMO, good combination of a powerful model and your ability to guide the model wisely.

[julien-nc]

@andreblanke Thanks a lot for the super fast feedback!