feat(enterprise): a machine policy file, also read by the VS Code extension

Enterprise mode could only be turned on by OPENCHAMBER_ENTERPRISE_MODE. On a
server that is fine, but on a laptop the desktop app reads it from the
user's login shell profile, which the user can edit. The VS Code extension
runs no OpenChamber server, so it ignored the mode entirely.

A policy file at a fixed, admin-only path (macOS /Library/Application
Support/OpenChamber, Windows C:\ProgramData\OpenChamber, Linux
/etc/openchamber) now turns it on as well. It can pin the relay and the Jev
endpoint and name the organization shown in Settings. The file wins over the
environment, nothing a user sets turns off what it turns on, and a file that
exists but cannot be read keeps the mode on and pins nothing. The policy is
read at every use in enterprise-mode.js, which the extension host bundles:
there it refuses provider connection and stops usage reporting on update
checks. The UI reads the policy from /api/openchamber/enterprise-policy on
every runtime, VS Code included.

The provider-connect refusal matched OpenCode 1 paths, so the real OpenCode
2 requests (connect/key, connect/oauth and its complete, connect/command,
experimental/integration/wellknown) went through. One matcher now covers
them on the server and in the extension host.

Security and classification provider docs explain the file in every
language.

Tested with the enterprise-mode, relay, routing, tunnels, tts,
notifications, opencode and package-manager suites, the ui i18n, settings
and routing store suites, the ui and vscode type-checks, and a vscode
extension build.