fix: /api/addstarr saves starr_id 0 for the new backend (stale starrs table) #119

Description of the bug

/api/addstarr can create the app access row with starr_id 0. In root/app/www/public/api/index.php, $starrsTable is read before the request is handled. The handler then calls $proxyDb->addStarrApp(...) and looks the new backend up with $starr->getAppFromStarrKey($request['apikey'], $starrsTable). That table is the stale copy without the row just inserted, so the lookup misses and intval($starrApp['id']) stores 0.

Expected behavior

The app created by /api/addstarr points at the starr backend that the same call just added.

Steps to reproduce

1. On a fresh install, add one Sonarr backend through /api/addstarr.
2. Add a second Sonarr backend through /api/addstarr with a different URL and key.
3. Check the apps table: the app for the second backend has starr_id 0, and requests with its scoped key are not routed to that backend.

Seen while testing on a throwaway container. Re-reading the starrs table after addStarrApp (or using the inserted id) should fix it.

Starr Proxy Version

develop at f48b99f

Deployment

Docker