Deprecate UserItem.Roles.UnlicensedWithPublish and .ViewerWithPublish (never accepted by the server)

Start by locating UserItem.Roles and how its class attributes are resolved; compare a class_getattr approach with a Roles.getattribute shim. Review _decompose_site_role and the behavior introduced by PR #1812. Done means accesses to both constants warn, their docstring records historical compatibility and server incompatibility, and existing invalid-user handling remains intact.

UserItem.Roles.UnlicensedWithPublish and UserItem.Roles.ViewerWithPublish are in the public API but have never worked as site role values against the Tableau server:

• POST /users (XML path used by users.add): RestApiSiteRole.fromString accepts the modern site roles plus a handful of v2 legacy names (Publisher, Interactor, Guest, SupportUser, SiteAdministrator, ReadOnly). Neither UnlicensedWithPublish nor ViewerWithPublish is in that enum on any REST API version I can see in monolith git history (back to 2023 Perforce snapshot).
• POST /users/import (CSV path used by users.bulk_add): CsvLicenseRoleTypeConverter accepts only creator/interactor/explorer/viewer/unlicensed/empty; any other value throws USER_CSV_INVALID_LICENSE. There is no site role → license translation before the license converter runs. UnlicensedWithPublish / ViewerWithPublish as literal license column values are rejected outright.

They've been in UserItem.Roles since the first commit of the library (2016-09-02) and have almost certainly been broken since Tableau Server 8.x/9.x-era licensing was replaced with the current Creator/Explorer/Viewer model.

Proposed fix:

• Emit a DeprecationWarning when either is accessed as a class attribute (via __class_getattr__ on a metaclass, or a Roles.__getattribute__ shim).
• Update the docstring to note the constants are retained for historical compatibility but do not correspond to any accepted server-side site role.
• Remove in a future major version.

Alternatively, if there is any historical or planned server behavior that would accept these strings that I have not found, please point at it and this issue can be closed.

Related

• PR #1812 refactored _decompose_site_role and initially defaulted unmapped site roles to Unlicensed, silently coercing these two roles to a valid-but-wrong user creation. That was changed to emit license="Invalid" (commit ac84fd3) so the server continues to reject the row instead of silently succeeding. This issue is the longer-term followup to properly deprecate the offending constants.