Fixes a regression that locked people out of their own Nuvio account.
What was wrong
The app shipped with an empty Supabase publishable key, on the reasoning that the official Android app reads it from local.properties at build time and so could not be redistributed. The reasoning was sound; the premise was wrong — the key is in Nuvio's public API docs, and this app's own earlier tvOS build carried it citing them. A sb_publishable_ key is meant to live in the client: row-level security protects the rows, not the obscurity of the key.
The cost was not a missing convenience. An empty key refuses both the QR flow and email/password at once, so the failure had no way out from inside the app.
It surfaced through an asymmetry worth recording: the session lives in the keychain, the server configuration lives in a file in the app container. Deleting an app on Apple platforms clears the container and leaves the keychain — so a reinstall was still signed in but no longer configured. It kept working on the stored token until you signed out, which removed the only thing holding it together.
What changed
- Nuvio's backend URL and key ship again. Nothing to paste to use a Nuvio account.
- A configuration that lost its key is repaired, at launch and on save. Emptying the fields now lands back on Nuvio's own backend.
- A self-hosted instance with no key is left exactly as it is — Nuvio's key would not authenticate against someone else's project, and writing it there would trade a legible "not configured" for a baffling 401.
- The account screen's copy no longer tells you to paste something that is already there.
- A test now asserts the shipped default is usable, which is what nothing did before. It was verified to fail: blanking the key turns four of its eight tests red.
Verification
206 unit tests, 8 UI tests, 0 failures. Built from a clean tree at the release commit.
Unsigned IPA — sideload with your usual signer.