fix(rbac): spell the group user type db_env_user, as the server does

[dudanogueira]

Motivation

rbac/groups/UserType spells its middle wire value db_end_user — end, not env. The server's enumeration is:

// entities/models/d_b_user_info.go:142
if err := json.Unmarshal([]byte(`["db_user","db_env_user"]`), &res); err != nil {

So DB_ENV_USER could never be produced by a read, and writing it would emit a value the server rejects. The constant is named DB_ENV_USER, so the intent is clear and only the string is wrong.

The typo survived because nothing uses this enum. grep -rn "UserType" src/ resolves every reference to rbac/users/UserType and none to this one. (GroupType, in the same package, is used — the package is not dead, this enum is.)

Approach

Correct the string to db_env_user.

Rejected, but worth your call: deleting the enum. It is an unreferenced duplicate of rbac/users/UserType, which already handles this value correctly via @SerializedName(value = "db", alternate = "db_env_user"). Deleting it would remove a trap — whoever wires up the groups client next would reach for the enum in their own package and get the broken one — and the typo is itself evidence that nothing has ever exercised it. I did not do that here because removing a public type is the more invasive call and it is yours to make.

No alternate spelling: db_end_user was never a value the server sent, so there is nothing stored under it.

Key areas for review

• Would you rather this deleted rbac/groups/UserType outright? It is a one-line change either way and I am happy to switch. See v6: groups/UserType spells db_env_user as db_end_user, and is an unreferenced duplicate #623 for the argument on both sides.
• The test row is deliberately for an enum nothing calls. It earns its place by pinning the vocabulary rather than the code path — but say if you would rather not have a test for an unreferenced type.

Testing

Unit — one round-trip row in JSONTest.testCases(), driving both test_serialize and test_deserialize.

Verified the test fails without the fix, in both directions:

expected:<DB_ENV_USER> but was:<null>
expected:<"db_en[v]_user"> but was:<"db_en[d]_user">

The read failure is the one that matters — an unknown enum string deserializes to null under Gson's default adapter rather than throwing, which is how a value like this stays wrong quietly.

No integration test: the enum is unreachable from any client call, so there is nothing to exercise end to end until it is wired up.

Locally green: 384 unit tests.

Breaking changes

None. The constant name and the enum's public shape are unchanged; only the wire string it maps to changes, and the old one matched nothing the server sends.

Conflict note

Adds a row at the end of JSONTest.testCases(), as #620 and #622 also do. Whichever merges last wants a trivial rebase.

Closes #623

🤖 Generated with Claude Code

https://claude.ai/code/session_01HNeKV7TAYZGDyT9agqJwUf

[orca-security-eu]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Infrastructure as Code	0   0   0   0	View in Orca
Passed	SAST	0   0   0   0	View in Orca
Passed	Secrets	0   0   0   0	View in Orca
Passed	Vulnerabilities	0   0   0   0	View in Orca

[bevzzz]

Please remove all comments from this PR and trim the PR description to what is strictly relevant.