User-addressed endpoints accept only id, not name (diverges from MS Graph id | userPrincipalName)

[dschmidt]

Context

MS Graph addresses users by {id | userPrincipalName} on user endpoints (see Get user and Get drive). OpenCloud is inconsistent: some user-addressed endpoints resolve id-or-name (via the identity backend), others only accept the opaque id.

Verified live:

• GET /v1.0/users/admin -> 200 (name works)
• GET /v1.0/users/admin/drive -> 404 (name did not work; id-only)

GetUserDrive is being fixed in opencloud-eu/opencloud#3243. This issue tracks the remaining id-only user-addressed endpoints, for consistency with MS Graph and for intentional spec documentation of the {user-id} parameter.

Remaining id-only endpoints (diverge from MS Graph)

Endpoint	operationId	why id-only
GET /v1.0/users/{user-id}/appRoleAssignments	user.ListAppRoleAssignments	raw param -> settings AccountUuid
POST /v1.0/users/{user-id}/appRoleAssignments	user.CreateAppRoleAssignments	raw param -> PrincipalId compare
DELETE /v1.0/users/{user-id}/appRoleAssignments/{id}	user.DeleteAppRoleAssignments	raw param
POST /v1.0/users/{user-id}/exportPersonalData	ExportPersonalData	raw param != ctxUser.OpaqueId (self-only)
GET /v1.0/users/{user-id}/photo/$value	GetUserPhoto	raw slug, no resolution

Already id-or-name (for reference): GetUser, PatchUser, DeleteUser, and GetUserDrive after opencloud#3243.

Decision needed

Per endpoint: either resolve name -> id via the identity backend (like GetUser does), or explicitly keep and document them as id-only in the spec. appRoleAssignments and exportPersonalData are admin/self operations that are in practice invoked by id, so id-only may be acceptable; the goal is to make the parameter semantics intentional and consistent rather than accidental.