Compose a namespaced Request for a namespaced composite

[mbakalarski]

The composed Request's API group was hard-coded to http.crossplane.io/v1alpha2,
which is cluster scoped. Crossplane refuses to apply a cluster scoped composed
resource for a namespaced composite, and fails the whole reconcile:

cannot compose resources: cannot apply cluster scoped composed resource
"eapi-probe-c1443be641" (a Request named ) for a namespaced composite resource

So this function cannot be used at all by a consumer whose XRD is
scope: Namespaced. netclab-xp is moving its entire surface to Namespaced and
hit exactly this — its EosCommand layer is blocked until this ships.

The change

Pick the group from the composite's own namespace, which the function already
reads a line above:

• namespaced composite → http.m.crossplane.io/v1alpha2
• cluster scoped composite → http.crossplane.io/v1alpha2, unchanged

Nothing else moves. Crossplane places a composed namespaced resource in the
composite's namespace by itself, and provider-http defaults providerConfigRef
to the ProviderConfig named default in that namespace — both confirmed on a
live cluster, so neither has to be spelled out here.

Verification

crossplane render against the running function, both ways, using the existing
example/ manifests:

XR	composed Request
example/xr1.yaml (no namespace)	http.crossplane.io/v1alpha2
same XR + namespace: lab	http.m.crossplane.io/v1alpha2

Unit tests: the existing one already covers the cluster scoped case, because its
fixture composite carries no namespace — it is the backward-compatibility guard.
The new one covers the namespaced case and asserts every composed resource, not
just the first.

Notes for the release

• function/__version__.py is bumped to 0.0.22, since ci-with-bnp.yaml
  fails the release when the tag and that file disagree.
• A namespaced Request requires provider-http >=v1.0.14, the first release
  serving http.m.crossplane.io. Consumers staying cluster scoped are
  unaffected.

🤖 Generated with Claude Code