fix: away-mode side resolution, IANA timezone lookup, keychain fallback

[omarshahine]

Summary

Three independent fixes that surfaced while testing #35 against a live Pod 2 Pro in Away mode.

1. Away-mode side resolution (internal/client/targets.go)

HouseholdUserTargets was reading each user's currentDevice.side, but the API overwrites that with the sentinel "away" for every user when the household is in Away mode. That broke --side left|right for anyone who'd ever used Away mode:

$ eightctl status --side left
Error: side "left" is not available for this household; available sides: away

The /devices payload has the authoritative assignment, just in a different shape in Away mode — the top-level leftUserId/rightUserId come back blank and the real IDs live inside awaySides as {"leftUserId":"…","rightUserId":"…"}. Read from there, fall through to the currentDevice.side value only when it's one of left/right/solo (never the Away sentinel), and filter the "available sides" error message to drop away.

Live verification (household currently in Away mode, two users):

$ eightctl status
side   name          user_id                           mode           level
left   Omar Shahine  b00bbaf376b846cfa0cf9e801fe510ce  smart:bedtime  -10
right  Lora Shahine  6354ffd8972c456c917126aac7eff310  smart:bedtime  -20

$ eightctl status --side left
side  name          user_id                           mode           level
left  Omar Shahine  b00bbaf376b846cfa0cf9e801fe510ce  smart:bedtime  -10

2. IANA timezone lookup (internal/cmd/timezone.go)

resolveAPITimezone previously fell back to UTC whenever time.Local.String() returned "Local" (which is the common case on macOS/Linux when $TZ isn't set — Eight Sleep rejects that value). Ports @dtrinh's /etc/localtime / /etc/timezone / $TZ resolution from #21 so presence, sleep day, sleep range, and metrics actually get the real local zone. Closes #21 with credit via Co-Authored-By.

Before:

$ eightctl presence --from 2026-04-10 --to 2026-04-17
WARN system local timezone is not an IANA zone; falling back to UTC for API queries
present
false

After:

$ eightctl presence --from 2026-04-10 --to 2026-04-17
present
false

3. Keychain backend fallback (internal/tokencache/tokencache.go)

defaultOpenKeyring listed KeychainBackend first in AllowedBackends, and the 99designs/keyring library picks the first backend whose Open() succeeds. On macOS sessions without a writable login keychain (which is more common than you'd expect — e.g., agent-spawned shells, kiosk accounts), Open() succeeds but every Set() fails with Keychain Error (-61), so the FileBackend fallback was never reached. The net effect: every CLI invocation re-ran the password grant, tripping Eight Sleep's auth rate limiter (401/429 on /tokens) after a handful of commands.

Save / Load / Clear now try the primary backend, and on write/read failure open a FileBackend-only ring pointed at ~/.config/eightctl/keyring/ and retry there. The OAuth token then survives between invocations as intended.

Live verification on a machine without a usable login keychain:

$ eightctl status --verbose  # run 1
DEBU primary keyring set failed; falling back to file backend error="Keychain Error. (-61)"
DEBU keyring saved token to file fallback
DEBU saved token to cache expires_at=…

$ eightctl status --verbose  # run 2
DEBU loaded token from cache expires_at=… user_id=…
DEBU using in-memory token expires_in=19h58m33s

No re-auth on subsequent invocations, no rate-limit bursts.

Test plan

• go test ./... — all pass, new tests cover each fix
  • TestHouseholdUserTargetsUsesDeviceMappingInAwayMode — Away-mode side resolution
  • TestResolveAPITimezoneUsesLocalIANAWhenValueIsLocal and TestExtractZoneinfoSuffix — IANA lookup
  • TestSaveFallsBackToFileWhenPrimarySetFails — keychain fallback via an unwritableKeyring fake
• go build ./..., go vet ./... clean
• Live verified against a Pod 2 Pro in Away mode with two users (see output above)

Refs #35 (follow-up), closes #21.