tg auth login: fall back to BSKY_HANDLE / BSKY_APP_PASSWORD #4

Summary#

tg auth login only reads ATPROTO_HANDLE and ATPROTO_APP_PASSWORD from the environment (see bin/tg ~L209, L212). On Claude Code on the Web, Anthropic provisions Bluesky credentials as BSKY_HANDLE / BSKY_APP_PASSWORD, so a SessionStart hook that simply runs tg auth login reports "unauthenticated" even though perfectly usable creds are sitting in the env.

Repro#

In a CCotw container with BSKY_HANDLE and BSKY_APP_PASSWORD set but no ATPROTO_*:

$ tg auth status
Not authenticated.

$ ATPROTO_HANDLE="$BSKY_HANDLE" ATPROTO_APP_PASSWORD="$BSKY_APP_PASSWORD" tg auth login
Logged in as austegard.com (did:plc:r2whjvupgfw55mllpksnombn)

That manual remap is the only thing standing between the hub session and authenticated tg usage.

Proposed fix#

In `cmd_auth_login`, after ATPROTO_HANDLE / ATPROTO_APP_PASSWORD, also consult BSKY_HANDLE / BSKY_APP_PASSWORD as a secondary source. ATPROTO_* should still win if both are set (it's the more specific name). Update the --handle help text on the auth login subparser (`bin/tg` ~L919) to mention the fallback once added.

This keeps the public interface ATProto-shaped while making the CLI usable in environments that only expose Bluesky-flavoured env vars (CCotw today, probably more hosted sandboxes tomorrow).

Why here vs. in the hub's boot.sh#

The hub repo's `boot.sh` could trivially do the remap before calling `tg auth login`, and arguably should. But anyone embedding `tg` in a similar hosted environment will hit the same wall, so a one-line fallback inside `tg` itself seems worth it. Happy to send a patch via `tg pr create` if you'd like.