docs: correct the Terminals isolation, context, and settings path notes

[silentoplayz]

Summary

Five small corrections to the Terminals pages. I checked each one by running the Terminals orchestrator 0.2.3 with Open WebUI 0.11.3 on the Docker backend.

• advanced/multi-user.md. The comparison table called the per user containers "fully isolated, separate everything". Files, processes, and resources are separate per user. On the Docker backend, though, every workspace sits on the same Docker network so the orchestrator can reach each one by name. That also lets a workspace reach a port another user's workspace has opened. The table cell, the two sentences that send untrusted deployments to Option 2, and the Option 2 bullets now say so and point mutually untrusted deployments at the Kubernetes backend with a NetworkPolicy. The Docker Backend and Kubernetes Operator links on the page all pointed at the Terminals index with no anchor, so they now go to its Deployment section.
• orchestration/contexts.md. The temporary chat bullet said a per chat terminal is never listed in the picker. It is listed until the temporary chat exists, and a message sent with it selected fails with Terminal unavailable: Terminal server '<name>' requires a saved chat context. The bullet now describes that. A new bullet notes that a proxy request carrying no chat id, such as a direct API call, lands in the shared workspace even under Per chat. The fallback sentence is scoped to the interface, which always sends the chat id.
• orchestration/policies.md. The settings path carried an unmatched bold marker and an extra step. It now matches the connecting page, Settings > Admin > Integrations, in the Open Terminal section.
• tab-deployment/Docker.md. One sentence in the naming paragraph explains the extra container provisioned for user id system, which Open WebUI uses to read a policy's tool list and system prompt.
• orchestration/environment-variables.md. One sentence under the injected resource variables explains why they exist, since nproc and free report the host's cores and memory from inside a capped workspace.

Related issue or discussion

No linked issue.

Checklist

• I have reviewed the relevant documentation and matched the existing style.
• This PR meets Open WebUI's contribution standards: it is accurate, relevant to users, narrowly scoped, maintainable, and not promotional content, advertising, lead generation, SEO placement, or a request to list a product, service, provider, integration, gateway, tool, or company primarily for visibility.
• I understand that PRs that do not meet these standards may be closed without review and will not be merged. Repeated, low-quality, off-topic, promotional, or intentionally misleading submissions may result in the contributor being blocked from future participation in Open WebUI repositories.

Notes for reviewers

Everything was measured on the Docker backend with two users on one instance. Text only, with no visual change.

• Cross-user port reach. From the second user's workspace, curl http://<first-user-container>:3000/file returned a file served by the first user's workspace. On the same workspace, localhost:3000 refused the connection, and the first workspace's own API on port 8000 answered 401 without its key.
• Temporary chats. With the connection on Per chat, the picker in a fresh temporary chat still listed the terminal. The first message failed with the error quoted above, and the picker dropped the terminal afterwards.
• Requests with no chat id. A proxy request with no X-Session-Id header reached the shared workspace while the row was on Per chat.
• The system workspace. docker ps showed a container labeled with user id system, provisioned when Open WebUI first read the policy's tool list.
• Resource variables. A workspace capped at one CPU and 1 GiB reported 20 cores from nproc and the host's total from free, while /sys/fs/cgroup/cpu.max and memory.max held the caps.