feat(enterprise): extensions from approved repositories, and a skill for the boundary

An extension that could send what it sees off the machine (an integration's
API, approved origins, an unsandboxed service) ran in enterprise mode like
any other, with only the user's approval behind it.

In enterprise mode such a package installs, updates and keeps those grants
only from a Git repository listed in the policy's allowedExtensions
(OPENCHAMBER_ALLOWED_EXTENSIONS). The list holds repository URLs, since a
package names its own id; an entry ending in / allows everything under it,
such as a whole organization. allowLocalExtensions lets developer machines
install from a local folder; ZIP stays closed. Install and update refuse the
rest with enterprise-mode, the catalog strips refused grants on every read so
a policy change counts at once, and approval cannot grant them. Settings
marks such an extension Not allowed and explains the rule in the Add tooltip.
Extensions that do none of this install as usual. The policy file is also
read when saved with a byte-order mark, as Windows PowerShell 5 writes it.

The new enterprise-boundary skill tells agents how to classify a change that
sends conversation content out, opens a way into the machine, adds provider
entry or reports usage, where to enforce it, when an administrator knob is
due, and how to walk every surface. AGENTS.md routes to it and pr-review
treats an ungated crossing as a finding.

Security docs gain the extension rules and an Examples section (policy file
on macOS, Linux and Windows, a Docker environment block); SDK docs tell
extension authors what enterprise mode means for them. Every locale.

Tested with the guests and enterprise-mode suites (a removed-protection run
turned the grant test red), the ui type-check, and the i18n, extensions and
integrations suites.