fix(agent-runtime): keep saved credentials for loopback controllers

[Dixith-dev]

I hit this while running the packaged desktop app with a local controller.

The controller itself was healthy and the normal proxy routes worked, but Workbench kept showing that it could not authenticate. /api/agent/models was returning a 401 even though the controller key had already been saved in the app.

The issue was in the controller merge logic. When the frontend sent an active controller URL without a browser-stored key, the agent runtime treated that request as a complete override and dropped the key from server-side settings. It was especially easy to trigger when one side used localhost and the other used 127.0.0.1.

This change:

• reuses the saved key only when the requested controller matches the saved controller
• treats localhost, 127.0.0.1, and ::1 as the same loopback endpoint
• keeps an explicitly supplied key as the highest priority
• never carries a saved key over to a different host

I added regression coverage for the matching URL, loopback alias, explicit key, and different-host cases.

Tested with:

• npm run test:integration — 64 passing
• the repository pre-push frontend quality gate
• a rebuilt desktop app against a local authenticated controller; the warning cleared and /api/agent/models returned 200

[0xSero]

No functional blocker found. Exact-head npm run check, 64 of 64 integration tests, runtime build, and 4 focused regressions all passed. Please refresh onto current dev, rerun CI on the refreshed SHA, then mark ready for review.

[Dixith-dev]

Updated this onto the current dev and marked it ready for review. I reran npm run check and npm run test:integration on the refreshed head; both pass, including all 101 agent-runtime tests. The new CI run is waiting for approval because it comes from a fork: https://github.com/sybil-solutions/local-studio/actions/runs/30951431962