Fix attributes() calling /userinfo instead of /attributes.json

[gclaro-idme]

Summary

• attributes() in IDmeAuth was hardcoded to call APIEndpoint.userInfo() → /api/public/v3/userinfo
• That endpoint returns OIDC standard claims — no status block — so callers received empty verification statuses and could not filter on subgroup
• Added APIEndpoint.attributes() → /api/public/v3/attributes.json and wired IDmeAuth.attributes() to use it

Root cause

APIEndpoint.kt had no attributes function. The attributes() method was reusing userInfo() by mistake, resulting in the wrong endpoint being called at runtime.

Test plan

• Verify APIEndpoint.attributes() returns {baseURL}api/public/v3/attributes.json for each environment
• Call attributes() end-to-end and confirm the response contains a populated status list with group, subgroups, and verified fields
• Confirm userInfo() and rawPayload() are unaffected (still call /userinfo)
• Cut a 1.0.1 release and have CVS bump their dependency

🤖 Generated with Claude Code

[ganaidme]

I verified that calling IDmeAuth.attributes() calls api/public/v3/attributes.json

[matt-james-idme]

Clean, targeted fix. The bug is exactly what the description says: attributes() was reaching for APIEndpoint.userInfo(...) and getting back OIDC claims with no status block, so any caller trying to filter on verification subgroup silently got nothing. The change is a one-line swap plus the missing endpoint function it should have been calling all along.

A few things worth calling out:

• The root cause framing in the description is accurate and helpful. This is a copy-paste bug, not a design issue, and the fix reflects that.
• The test coverage is right-sized for the change. attributes calls attributes endpoint not userinfo locks in the bug so it can't regress, and the two response-shape tests confirm the status and attributes deserialization path that was never actually exercised against the real endpoint before.
• Using endsWith("api/public/v3/attributes.json") in the URL assertion is the right call - it stays robust across environments without overfitting to a specific base URL.
• APIEndpoint.attributes() slots in cleanly next to userInfo() and policies() with consistent formatting and a docstring. Nothing else to touch.

One thing to confirm before cutting 1.0.1: worth a quick manual smoke against staging to make sure the real attributes.json response deserializes into AttributeResponse without surprises - the tests use a hand-crafted JSON fixture, so any field-name drift between the fixture and the live response wouldn't be caught here. The test plan already has this covered.

Good to merge once that's verified.