fix(server): keep the API base path prefix and scope the launcher profile

The paperclip-api helper dropped any path prefix from PAPERCLIP_API_URL by
taking only the URL origin, so a reverse-proxied deployment sent every
request to the wrong path. It now keeps the normalized base, including its
prefix, and rejects a path that resolves outside that prefix. A generated
property test with 200 cases and a named table cover this.

A host-credentials run now stages the token-free paperclip-api helper, but
it also picked up a forced PATH/ZDOTDIR/BASH_ENV and six shell profile files
meant for a managed Git credential run. That silently narrowed the host's own
shell setup. The launcher now applies the profile redirection only when it
also stages git or gh, and a host-credentials run keeps only its PATH entry
and the launcher directory. A login shell can still reorder PATH ahead of the
launcher directory on a host-credentials run; nothing here restores it, since
doing so would again override the host's own profile. This is a known,
accepted residual.

The API access note rendered from a launcher directory alone, so a future
caller that stages only git and gh, without paperclip-api, could still make
the note teach a command that is not on PATH. The launcher now reports its
staged program list, and the note reads that list instead of the directory.

Co-Authored-By: Paperclip <noreply@paperclip.ing>

server/src/services/heartbeat.ts

@@ -1441,6 +1441,7 @@ const FORBIDDEN_ENV_BINDING_KEYS = new Set([
   "PAPERCLIP_GITHUB_BROKER_URL",
   "PAPERCLIP_GITHUB_BRIDGE_TOKEN",
   "PAPERCLIP_GITHUB_LAUNCHER_DIR",
+  "PAPERCLIP_GITHUB_LAUNCHER_PROGRAMS",
 ]);
 const MANAGED_GITHUB_TOKEN_KEYS = new Set([
   "GH_TOKEN",