New repo: crossplane-contrib/provider-environment-configs

**Name of new extension**

`provider-environment-configs` (repo: `crossplane-contrib/provider-environment-configs`)

**Purpose and intended scope of the extension**

Crossplane v2 made composite resources (XRs) namespaceable (Compositions themselves remain cluster-scoped). A namespaced XR can't compose cluster-scoped resources, and `EnvironmentConfig` (`apiextensions.crossplane.io/v1beta1`) is cluster-scoped — so there is no way for a namespaced composite to create one, which breaks patterns like sharing a value (e.g. an `id` from one managed resource's `status.atProvider`) by having one composite produce an `EnvironmentConfig` that another consumes. See crossplane-contrib/function-environment-configs#105.

A function can't solve this on its own: the package manager does not install CRDs bundled in *function* packages — the [xpkg spec](https://github.com/crossplane/crossplane/blob/main/contributing/specifications/xpkg.md#function-package-requirements) allows CRDs there only to deliver input-type schema, and the function-revision controller filters them out. A **provider** is the only package type whose CRDs the manager installs, so a small provider is the natural home for a namespaced equivalent.

Alternatives considered and rejected: adding a namespaced `EnvironmentConfig` to core itself — e.g. under `apiextensions.m.crossplane.io`, mirroring the `.m.` namespaced-group convention providers adopted in v2 — would be the most native option, but it carries a longer core release timeline and cuts against a long-standing inclination in the project to move `EnvironmentConfig` *out* of core rather than expand it there. The remaining alternatives were all raised in #105: creating the cluster-scoped `EnvironmentConfig` indirectly via a `provider-kubernetes` `Object` (painful, cluster-scoped, and against the namespaced direction of v2); or exposing values in the composite's `status` and reading them via `function-extra-resources` (leaks confusing internal details into the end-user's composite status). Of these, a small contrib provider is the pragmatic path: it needs no core change to ship, and can be deprecated cleanly if core ever grows a namespaced `EnvironmentConfig`.

Initial scope:
- A **namespaced** `EnvironmentConfig` CRD under a new API group, `environmentconfigs.crossplane.io/v1alpha1`, distinct from the cluster-scoped `apiextensions.crossplane.io` one, with the same schemaless `data` contract.
- A lightweight controller that marks instances Ready — composed resources need a Ready signal, so this is what lets producers compose the CRD without an `AlwaysReady` check in every Composition.
- Companion to function-environment-configs, which will gain (as planned follow-up in that repo) a configurable `apiVersion`/`kind` + `namespace` selector, defaulting to today's cluster-scoped kind, to load these.

Possible future improvements:
- Server-side aggregation: the controller resolves label/name selectors across `EnvironmentConfig`s and materializes a merged result in `status.data`, moving that work out of the function for the cases that don't depend on the consuming XR.
- A cluster-scoped variant, so the provider can offer both scopes.
- If core ever chooses to move `EnvironmentConfig` out of tree, this repo could inform or host that — but deprecating a core API is explicitly out of scope here and would be raised separately in crossplane/crossplane.

Non-goals: it is not a managed-resource provider for any external API; it has no `ProviderConfig` and reconciles no external system. We use the provider package type purely as the CRD-delivery mechanism.

**Initial maintainer team (GitHub usernames)**

- @phisco — maintainer of function-environment-configs and Crossplane maintainer (Upbound)
- @tenstad — author of https://github.com/crossplane-contrib/function-environment-configs/issues/105 and the originating use case

**Description of the maintainer team's long term commitment to the extension**

@phisco already maintains function-environment-configs and intends to keep doing so for the foreseeable future; this provider is a thin companion that evolves with it, so the marginal maintenance cost is small. @tenstad brings the originating use case and has agreed to co-maintain, giving the project more than one active maintainer from the start. We commit to keeping it compatible with current Crossplane releases, triaging issues and PRs, and cutting releases alongside the function. If at any point the team can no longer maintain it, we'll work with the steering committee to find new maintainers or archive it cleanly.

Start by reading the Crossplane xpkg function-package requirements and the use case in function-environment-configs#105. Define the new provider package with a namespaced environmentconfigs.crossplane.io/v1alpha1 EnvironmentConfig CRD and a controller that marks instances Ready. Done means the package delivers the CRD and composed resources receive a Ready signal without an AlwaysReady check.

Written by the indexing model from the issue text.