fix(cli): authenticate auth register from the logged-in environment

[Caushi]

Stacked on #573 — base is feature/cli-auth-ux, so this diff is just the auth register fix. Review/merge #573 first; GitHub will retarget this to main once it lands.

The bug

auth register prompted for an Employee Bearer token whenever neither --token nor --config-env was given — so immediately after a successful bfabric-cli login you still had to paste a token by hand:

$ uv run bfabric-cli login
Authenticated successfully.
Config saved to environment 'local' in ~/.bfabricpy.yml

$ uv run bfabric-cli auth register my-app http://localhost:6666
Employee Bearer token:      # ← should not be asking

The changelog already promises that every auth command resolves the environment as --config-env > BFABRICPY_CONFIG_ENV > configured default. register was the one command that didn't — it treated "no --config-env" as "prompt" instead of "use the default".

Changes

• Respect the environment in effect. With no --token, register now authenticates as the resolved environment, so login → register just works. --token still works for supplying one explicitly.
• Reuse connect() instead of reimplementing it. The old code rebuilt the OAuthCredentialProvider + token-cache lookup by hand (~40 lines). Bfabric.connect() already resolves the environment (including the "default" sentinel), loads the cache, and raises the "log in first" errors — register_webapp was already using exactly this. Net −12 lines in register.py despite adding a flag.
• Require an explicit service-user choice, matching what feat(cli): redesign bfabric-cli auth UX #573 does for register-webapp: --service-user LOGIN or the new --no-service-user. Silently defaulting to none registers a client without the client_credentials grant.
• Fixed two now-stale help/error strings (--token's "prompted if omitted", and "base_url is required when --config-env is not provided").

Deliberate behaviour change

A non-OAuth (password) environment is no longer pre-screened. Previously register printed Environment 'X' does not use OAuth locally; now connect() hands back the SOAP password, it's sent as a bearer token, and the server rejects it (405). Validating that belongs in connect() — not bolted onto one CLI command — so it's left out rather than duplicated here. test_config_env_non_oauth_sends_configured_password documents the new behaviour.

Open question, not addressed here

register / register-webapp may be in the wrong place. Every other top-level group is noun-shaped (api, dataset, executable, workunit), while auth is verb-shaped — session state. These two create durable server-side objects (an OAuth client, plus a B-Fabric application entity, with --technology-id / --application-id / --description fields), which is noun work. Something like bfabric-cli oauth-client register may fit better, but that's a user-visible rename and deserves its own discussion.

Testing

• 224 bfabric_scripts tests pass; 16 in test_cmd_login_register.py, incl. new coverage for default-env resolution, BFABRICPY_CONFIG_ENV precedence, explicit --config-env winning, and the service-user choice.
• Tests now seed the real on-disk token cache instead of mocking OAuth2Session, so they exercise the path connect() actually takes. Two of them previously made live HTTP requests to example.com; both are now mocked.
• ruff check and basedpyright(bfabric_scripts) clean (0 errors).
• Verified manually: auth register no longer prompts, and both commands now show --service-user / --no-service-user.

[leoschwarz]

Looks good to me.