fix(db_init.sh): resolve services id dynamically — fixes 503 "unable to get a node" on fresh deployments

[tmiland-labs]

Problem

Since syncstorage-rs 0.21.1 (tokenserver-mysql), the tokenserver resolves the sync service by name and then matches nodes.service against that id:

• get_service_id: SELECT id FROM services WHERE service = 'sync-1.5'
• get_best_node: SELECT id, node FROM nodes WHERE service = ? ... (tokenserver-mysql/src/db/db_impl.rs)

The upstream migration chain guarantees that sync-1.5 does not have id 1 on a fresh database:

1. 2021-08-03 populate_services inserts sync-1.1 (id 1) and sync-1.5 (id 2)
2. 2021-12-22 remove_services deletes the rows (AUTO_INCREMENT counter is not reset)
3. 2026-02-26 add_sync15_service re-inserts sync-1.5 — it lands on id 3

db_init.sh hardcodes nodes.service = '1', so the node row never matches and every login fails with 503 "Unexpected error: unable to get a node" on current images. Verified on a completely fresh stack (docker compose down -v && up): services shows sync-1.5 at id 3 while the seeded nodes row points at service 1.

Fix

• Look up the services id by name when inserting the node row
• Make the nodes upsert self-healing: ON DUPLICATE KEY UPDATE also refreshes service, which repairs databases initialized by the old script
• Replace the explicit-id INSERT IGNORE with a name-based guard so duplicate sync-1.5 rows can't be created
• Fix pre-existing shellcheck SC2086/SC2006 findings (quoting, $( ))

Verification

• Tested against MariaDB with drifted / fresh / duplicate-name database states (script is idempotent across restarts)
• Confirmed working end-to-end with Firefox against syncstorage-rs 0.21.1-based images: login + sync succeed, services.id == nodes.service consistent after init