Opt an organization in to community add-ons, or out

Installs a catalog add-on at a scope: `org`, `project`, `sandbox` or `atlas_workspace`. Every install passes the same checks, in this order, each refusal with its code. The listing exists and the caller can see it in the org's catalog (`addon_not_found` otherwise), and the caller holds the kind's `.manage` at the scope (`skills.manage`, `mcp.manage`: at the org, on the project, or on the sandbox's project). Only then: the listing is not `blocked` or `retired`; the scope is one of its `attachLevels`; the org's policy allows it (community add-ons need the org's opt-in or an explicit allow); the org holds it (free, included in its plan, or bought: installing never buys); and nothing above the scope has switched it off. Today skills and MCP servers install on a project, one install of a listing per project. A resource is allocated, on a project (the default for its sandboxes) or one sandbox, by `config.quantity`, under `resources.manage` on the project (a sandbox's own project); posting again for the same scope changes its quantity. After the checks above, an allocation also needs, in this order: a quantity; a sandbox no more than its project's default (`resource_exceeds_project`); the org's allocations of the resource within what it bought (`resource_quantity_exceeded`); the plan's cap for it, and a plan with none refuses (`resource_quota_not_set`, `resource_quota_exceeded`); for a resource billed on use, the org's own cap (`resource_org_cap_not_set`, `resource_org_cap_exceeded`); and room on a host (`addon_capacity_unavailable`, 503). Plugins are not installable yet (501), every install and allocation is audited, and apps are added to an Atlas workspace from Atlas.