fix(member): use canonical Harbor role IDs and surface API errors

[dev-aditya-hub]

Summary

While testing harbor project member create, I noticed --roleid 1 was creating a Developer instead of a Project Admin, and a failing API call still printed successfully added user .... Tracing it, the role ID had two different representations in the codebase and one of them was being silently shifted.

This PR makes the Harbor role ID (1=Admin..5=LimitedGuest) the only representation past the cobra layer.

Changes

• pkg/api/member_handler.go: drop the +1 shift in CreateMember; the wrapper now passes RoleID through unchanged.
• pkg/views/member/create/view.go: bind the interactive role select directly to the existing RoleOptions map (1..5) instead of slice indices (0..4), so the form and the flags share one representation.
• cmd/harbor/root/project/member/create.go:
  • Add resolveRoleFlags to normalize --role and --roleid into a single canonical ID, with explicit validation and conflict detection (previously --role was registered but never resolved).
  • Return wrapped errors from GetSystemInfo and CreateMember instead of logging them and falling through to the success message.

Behavior

Input	Before	After
--roleid 1	creates Developer (id 2)	creates Project Admin (id 1)
--role Developer	flag silently ignored, falls into interactive prompt	creates Developer
--role Foo	falls into interactive prompt	rejected with a clear error
--role Admin --roleid 3	conflict silently ignored	rejected with a clear error
API call fails	prints "successfully added", exits 0	wrapped error, non-zero exit

Test plan

• harbor project member create <p> --username <u> --roleid 1 creates a Project Admin
• harbor project member create <p> --username <u> --role Developer creates a Developer
• harbor project member create <p> --username <u> --role Foo fails with a clear message
• Interactive flow still works and assigns the role shown in the picker
• A failing create (e.g. duplicate member) exits non-zero

[dev-aditya-hub]

Hi @qcserestipy, when you have a moment, could you take a look at this PR?

Short version of the bug: harbor project member create --roleid 1 was creating a Developer instead of a Project Admin because the API wrapper silently added 1 to the role ID (the form picker was 0-indexed, the flag is 1-indexed, and the +1 in CreateMember papered over only the form path). On top of that, --role <name> was registered but never resolved, and a failing API call still printed "successfully added" and exited 0.

The PR makes the canonical Harbor role ID (1..5) the only representation past the cobra layer, validates --role/--roleid at the boundary, and propagates API errors. Six files, ~50 lines.

Thanks!