fix: prevent silent config loss and misleading post-configure errors (F293433)

[samsolaimani]

Summary

Fixes two bugs in alks developer configure that together caused users to get stuck in a "Server URL is not configured" loop and see misleading error messages.

---

US1985865 — Fix updateDeveloper double-loadDatabase orphaning collection reference

Root cause: updateDeveloper obtained a LokiJS collection reference via getCollection(), then called getDeveloper() which internally called getCollection() a second time. Each call invokes db.loadDatabase() — when alks.db exists on disk, LokiJS resets db.collections and rebuilds from disk, orphaning the first reference. When the loaded collection has zero records, the developer object is a fresh {} (not a live reference), so subsequent writes target the orphaned collection and db.save() drops the update silently.

Fix: Call getDeveloper() first so the DB is loaded, then call getCollection() — guaranteeing the reference is attached to the live, post-load db.collections.

Tests added: src/lib/state/developer.test.ts — integration tests against a real LokiJS file using a tmpDir + ALKS_DB env var. Includes a regression test that seeds alks.db with an empty account collection to reproduce the exact failure mode.

---

US1985867 — Wrap non-critical post-configure steps in try/catch

Root cause: Optional post-save steps (tab completion install, update check) ran inside the same top-level try/catch as the critical configuration writes. Any failure there called errorAndExit('Error configuring developer: ...') — a misleading message since the configuration had already been persisted successfully.

Fix: Moved both optional steps outside the main try/catch, each with its own try/catch that warns and continues. Configuration is always preserved; only the warning message changes.

---

Test results

All 400 tests pass. tsc --noEmit clean. No new lint warnings.

---

Refs: F293433, US1985865, US1985867

🤖 Generated with Claude Code

[DevOpsDave]

Approve

Both fixes are correct and well-tested.

US1985865 (silent config loss): The root cause — getCollection calling db.loadDatabase() which resets db.collections and orphans a previously-obtained collection reference — is accurately diagnosed. The reorder (call getDeveloper first, then obtain the collection reference) guarantees writes target the live, post-load collection. The removal of the redundant removeDataOnly() is correct. The new integration tests in developer.test.ts cover the regression case (empty account collection on disk) well.

US1985867 (misleading error message): Moving post-configure steps (tabtab.install, checkForUpdate) outside the main try/catch with their own warning-level error handling is the right approach. Config is always preserved; only optional steps degrade gracefully.

Test expectations updated correctly. CI builds pass on Node 20/22/24. SonarQube upload failure is infra-related.