createsiteusers swallows ServerResponseError details, making failed rows unactionable

Start in tabcmd/commands/user/create_site_users.py:57-73 and trace how ServerResponseError is logged and added to error_list. Use the provided createsiteusers CSV scenario to inspect the resulting summary. Done means failed rows include actionable server response code, summary, or detail instead of only the exception class name.

Problem

When tabcmd createsiteusers fails on rows in the CSV, the summary just prints the exception class name — the actual server response (error code, detail message) never reaches the user, even at -l DEBUG or -l TRACE.

Repro

Any CSV that causes rows to fail. Example: a site that requires email-format usernames, given a CSV with non-email usernames like jsmith.

Output:

Lines processed: 4
Lines skipped: 4
Number of users added: 0
Error details:
['ServerResponseError', 'ServerResponseError', 'ServerResponseError', 'ServerResponseError']

The user can't tell whether the failures are invalid-license-level, invalid-email, duplicate-user, missing-permission, etc.

Root cause

tabcmd/commands/user/create_site_users.py:57-66 catches TSC.ServerResponseError and calls logger.debug(e) — but the underlying logger for CreateSiteUsersCommand has an effective level of INFO, so DEBUG calls are dropped. Even passing -l DEBUG doesn't surface them (verified — 21-line trace log shows no exception detail lines).

Additionally, only the exception class name is added to the error_list that's summarized at line 73. The commented-out fragment # + ": " + e.__cause__ or "Unknown" suggests someone previously considered including cause detail and pulled it out.

Suggested fix

At create_site_users.py:65, format the error's HTTP status / code / detail into the error_list entry alongside (or instead of) the class name. TSC's ServerResponseError exposes .code, .summary, and .detail — including these in the summary would make row failures actionable.

Optionally, bump the logger.debug(e) call at line 58 to logger.warning or logger.error so the exception surfaces without needing to increase log level.

Impact

Anyone hitting a row-level failure with createsiteusers (or the underlying UserCommand.add_users) currently has to open the source and inject their own logging to figure out what went wrong. Common failure modes (invalid email format on Cloud sites, wrong site role, duplicate user) all look identical in the output today.