fix(remote): forward nested service cache files to and from the server

Cache keys are now the path relative to the service cache dir without .json, so Cacher keys like session_web/<sha1> reach the remote session. The credential filter runs on every path segment, the suffix is appended rather than substituted, and both sides cap the map at 64 keys.

docs/dev/rest-api/endpoints.md

@@ -857,7 +857,7 @@ DELETE /api/session/{id}        → tear down, harvest updated cache
 
 ### `POST /api/session/create`
 
-Make a remote session for a service and title. Authentication runs asynchronously in the background. This call returns immediately with `status: "authenticating"`, and you then poll the prompt endpoint. The body accepts `service` and `title_id` (both required). It also accepts a broad set of optional keys, because the body allows `additionalProperties`. These are `credentials` (`{username, password, extra?}`), `cookies` (base64 of zlib-compressed Netscape cookie file), `proxy`, `no_proxy`, `profile`, `cache` (map of forwarded cache files), `client_region`, `proxy_region`, `cdm_type`, `range_`, `vcodec`, `quality`, `best_available`, `client`, and any service CLI options. `proxy_region` is the country code the client resolved `proxy` from; the server matches it against its own accounts. `client` is a freeform object the dashboard shows as sent (the CLI puts `version`, `code_hash`, `platform` and a redacted `argv` in it); the server ignores it above 4096 bytes of JSON.
+Make a remote session for a service and title. Authentication runs asynchronously in the background. This call returns immediately with `status: "authenticating"`, and you then poll the prompt endpoint. The body accepts `service` and `title_id` (both required). It also accepts a broad set of optional keys, because the body allows `additionalProperties`. These are `credentials` (`{username, password, extra?}`), `cookies` (base64 of zlib-compressed Netscape cookie file), `proxy`, `no_proxy`, `profile`, `cache` (map of forwarded cache files, keyed by the file path relative to the service cache directory with `/` separators and no `.json` suffix, so a nested key such as `session_web/<sha1>` lands in a subdirectory), `client_region`, `proxy_region`, `cdm_type`, `range_`, `vcodec`, `quality`, `best_available`, `client`, and any service CLI options. `proxy_region` is the country code the client resolved `proxy` from; the server matches it against its own accounts. `client` is a freeform object the dashboard shows as sent (the CLI puts `version`, `code_hash`, `platform` and a redacted `argv` in it); the server ignores it above 4096 bytes of JSON.
 
 Service CLI options also travel in a nested `service_params` object, which wins over a flat key with the same name. `profile` at the top level always means the credentials profile, never a service's own `--profile` option.
 
@@ -1130,11 +1130,11 @@ Tear down a remote session. The server cancels its input bridge, harvests any up
     ```json
     {
       "status": "ok",
-      "cache": { "tokens.json": "<base64 zlib bytes>" }
+      "cache": { "tokens": "<base64 zlib bytes>", "session_web/<sha1>": "<base64 zlib bytes>" }
     }
     ```
 
-The `cache` field is present only if the remote session produced cache files and the login belongs to the client. `404 SESSION_NOT_FOUND` if the remote session does not exist.
+The `cache` field is present only if the remote session produced cache files and the login belongs to the client. Each cache key is the file path relative to the session cache directory, with `/` separators and no `.json` suffix, so a file in a subdirectory keeps its place on the client. The server rejects a cache key with a drive letter, a root, a `..` segment, or an empty segment, and so does the client. `404 SESSION_NOT_FOUND` if the remote session does not exist.
 
 ---
 

docs/dev/rest-api/remote-sessions.md

@@ -124,11 +124,13 @@ hood the client walks a remote session through its lifecycle.
       the client region itself
     - Track-selection hints (`range_`, `vcodec`, `quality`, `best_available`) so
       the server fetches the right manifests
-    - Your local per-service **cache files** (e.g. refreshed tokens), but only the
-      files for the active profile. The client withholds a file whose name embeds
-      a hash of another credential, or the name of another profile. One profile's
-      tokens therefore never reach the server while you use a different profile.
-      At worst, a withheld file makes the server authenticate again
+    - Your local per-service **cache files** (e.g. refreshed tokens), including
+      files in subdirectories of the service cache directory, but only the files
+      for the active profile. The client withholds a file whose path, in any
+      directory or file name, embeds a hash of another credential or the name of
+      another profile. One profile's tokens
+      therefore never reach the server while you use a different profile. At
+      worst, a withheld file makes the server authenticate again
 
     The server uses its own accounts only when the operator lists the service in
     `serve.server_accounts` and gives your API key `server_accounts` in `serve.users`.
@@ -430,14 +432,28 @@ _sessions/<pbkdf2_hmac(sha256, X-Secret-Key, "unshackle-session-ns", 100000)[:12
 
 The handler writes forwarded `cache` files into that directory before authentication.
 On `DELETE`, when the login belongs to the client (`client_auth`), the handler
-harvests updated cache files (compressing each with zlib and base64-encoding,
-**excluding** `titles_*` files) and returns them under a `cache` field, so the
-client can keep refreshed tokens:
+harvests updated cache files from the whole directory tree (compressing each
+with zlib and base64-encoding, **excluding** `titles_*` files) and returns them
+under a `cache` field, so the client can keep refreshed tokens. Each cache key
+is the file path relative to that directory, with `/` separators and no `.json`
+suffix, which is the `Cacher` cache key the service reads it with:
 
 ```json
-{ "status": "ok", "cache": { "tokens": "...base64(zlib(bytes))..." } }
+{
+  "status": "ok",
+  "cache": {
+    "tokens": "...base64(zlib(bytes))...",
+    "session_web/<sha1>": "...base64(zlib(bytes))..."
+  }
+}
 ```
 
+Both sides reject a cache key with a drive letter, a root, a `..` segment, an empty
+segment, or more than 8 segments before it becomes a path, so a peer cannot write
+outside the cache directory. Both sides also refuse a `cache` map with more than
+64 entries. The server skips a cache key it cannot write, such as one that names an
+existing file as a directory, and logs a warning.
+
 ### Remote session info response
 
 `GET /api/session/{id}`: