Bug/login and device discovery

[lsiddiquee]

Summary

Login & device-discovery hardening across 1.0.15 → 1.0.22, with the final two
versions (1.0.21 + 1.0.22) bundled into a single 1.0.22 publish because 1.0.21
was rate-limited by the Homey App Store and never went live.

Closes / addresses the reports in issue #108 from aagehellem, silvinnio and
others — "Authorization Failed" appearing after sign-in actually succeeded,
container limit (CU-429) cascading into permanent failures, retry burning extra
device-code requests, and stale leftover container entries blocking new pairings.

What changed

1.0.22 — Distinct post-auth failure UX + retry short-circuit

• setup_error event split from authentication_error: when sign-in
  succeeds but the post-auth container step fails (e.g. CU-105, CU-429), the
  driver now emits setup_error instead of authentication_error. The pair
  view shows a "Device Setup Failed" title with an explicit hint that sign-in
  is kept, so users no longer think their authorization failed when it didn't.
• request_device_code short-circuits on stored valid tokens: the
  "Try Again" button no longer re-requests a device code when sign-in is
  still valid. The handler now calls getValidAccessToken() first and, on
  hit, runs only the container step + advances the view. Saves one OAuth
  round and one slot from BMW's 50/24h request quota per retry.
• Frontend tolerates a { skipCode: true } sentinel so the loading spinner
  stays up while the backend drives the view transition.

1.0.21 — Progressive container cleanup (folded into 1.0.22)

• Container cleanup is no longer all-or-nothing. The app removes one
  stale leftover container per pairing attempt rather than trying to clear
  every old entry at once, so a quota-hit on delete doesn't block the create.
• Zero deletes when an existing entry is being reused.
• CU-429 from the delete call propagates to the user so they understand
  the daily limit was hit, while other delete errors are swallowed so a
  single bad leftover doesn't block the create.

1.0.15 → 1.0.20 (already published, recapped for context)

• PKCE device-code OAuth flow stabilization
• Token persistence in pollForTokens before container step
• HomeyTokenStore migration + cleanup
• DeviceCodeAuthProvider error categorization (auth-pending vs. denied
  vs. expired)
• Pair / repair flow alignment using shared device_code.html

Files of note

• drivers/ConnectedDriver.ts — setup_error emission +
  request_device_code short-circuit + progressive cleanup
• shared/pair_repair/device_code.html — split title, hint paragraph,
  separate setup_error listener, skipCode handling
  (auto-copied into drivers/{bmw,mini}/{pair,repair}/ by prebuild)
• locales/en.json — pair.device_code.setup_error.{title,hint}
• lib/api/ContainerManager.ts — progressive cleanup behaviour
• tests/drivers/ConnectedDriver.comprehensive.test.ts — asserts new
  setup_error event + that authentication_error is NOT emitted on
  post-auth container failures

Validation

• 614 tests passing across 31 suites
• npm run validate clean (prettier + eslint + markdownlint, 0 errors)
• homey app build clean (publish-level validation passes)
• 1.0.22 published: Build 78 uploaded to the Homey App Store
• Manual regression checks against the issue Error Message #108 user reports

Notes for reviewers

• app.json diff is generated from .homeycompose/ by homey app build
  and is committed for at-a-glance review of capabilities and flows.
• The four drivers/{bmw,mini}/{pair,repair}/device_code.html diffs are
  identical and are auto-generated from shared/pair_repair/device_code.html
  by the prebuild step. Edit the shared file, not the copies.