muster release v5.44.1

Fixed

• A server that refuses the stored grant on connect answers its sign-in link, not a 401. A session marked signed in to an OAuth server but without a live connection to it (after a restart, or once the pooled connection was retired) opens one on its next tool call; when the server refused the stored token on that handshake, every call failed with failed to initialize on-demand client ... 401 while muster auth status kept showing the server connected. The call now answers the server’s auth_required challenge with its sign-in link, as a 401 during a call already did: the refused grant is dropped, the session is no longer marked signed in to the server, and core_auth_login issues the sign-in. muster auth login --force --server <name> signs out of a server the session reads connected and signs in to it again; without --force the command says so instead of claiming the server needs no authentication. (#1574)
• A core_auth_login that starts no OAuth flow no longer spends the person’s authentication attempts. Every call was charged to the per-user rate limit (10 attempts a minute) before muster looked at the session, so a client checking a server’s connection with core_auth_login (the portal does before it acts for the person) used up the attempts with answers like “already authenticated” and the next real sign-in was refused with “Rate limit exceeded … Remaining attempts: 0”. An attempt is now charged only when the answer needs an OAuth flow, a held grant reused or a new challenge; answers that start none (already authenticated, no authentication needed, a deactivated or SSO-managed server) are free. The limit itself is unchanged. (#1567)