Let a bot and a workspace set their own envs

Envs had three scopes, general, workspace and computer. A bot had no
scope of its own, so the only way to give one worker a key was to set it
on a computer it happened to share.

The envs table gets a bot_id, and resolution now layers bot over
computer over workspace over general, so a bot's own key wins wherever it
runs. Every computer call site passes the run's bot_id, and grabRunEnvs
does the same for the {{env.KEY}} a custom tool or an MCP server's headers
read.

A bot's and a workspace's settings page can now edit their own envs, in
place, through the same save-env and delete-env routes: sending `scoped`
makes them answer with just that scope instead of the whole install's
overview. Super admins only, like the Environment page.

src/pages/admin/settings/(functions)/post-env-api.ts

@@ -0,0 +1,24 @@
+import fetchApi from "@moduletrace/twui/utils/fetch/fetchApi";
+import type { APIResponseObject } from "@moduletrace/bunext/types";
+import type { EnvsMutationResult } from "@/src/types";
+
+type Params = {
+    /**
+     * Under `/api/admin/envs/`.
+     */
+    path: "save-env" | "delete-env";
+    body: Record<string, unknown>;
+};
+
+/**
+ * Posts to an env API route. Every route answers with the fresh page data
+ * in `singleRes`: the whole Environment overview, or just the one bot's or
+ * workspace's envs (the settings pages, `body.scoped`), so the page updates
+ * in place.
+ */
+export default async function postEnvApi({ path, body }: Params) {
+    return await fetchApi<Record<string, unknown>, APIResponseObject<EnvsMutationResult>>(
+        `/api/admin/envs/${path}`,
+        { method: "POST", body },
+    );
+}