Point the panel link at the installation, not at the browser's origin

Both links out of the dashboard editor were built root-relative, so a portal
serving the app under `/i/{id}` got a URL to itself: the hub has no route
there and answers a bare 404. That is what a device link and "open what a
wall panel sees" both landed on.

They want different answers. The view link is for the person already looking,
so it takes the router's basepath — `appPath` in `lib/portal` is the same
prefix the router applies to every `Link`, for the places that step outside
it. The device link is for a screen, which cannot go through the portal at
all: the shell is served only to a portal session, and the credential that
page carries is the portal's rather than the panel's. So the server now says
where it answers, and `FRONTEND_HOST` is that answer — the same setting the
password-reset links already use.

Also fixes the panel branch in the query error handler, which compared a raw
pathname and so never fired under a portal.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AHpLJHozysQXjsxAyU1WHj

backend/tests/api/routes/test_panels.py

@@ -56,6 +56,9 @@ def test_assign_and_read_back(
 
     stored = client.get(f"{PREFIX}/", headers=superuser_token_headers).json()
     assert stored["panels"][0]["dashboards"] == ["hall_a", "hall_b"]
+    # The address a device is pointed at comes from the server, because the
+    # browser's own origin is the portal's when someone administers remotely.
+    assert stored["frontend_host"] == settings.FRONTEND_HOST.rstrip("/")
     assert (
         client.get(f"{PREFIX}/hall", headers=superuser_token_headers).json()["title"]
         == "Hall"