CloudFoundryEnvironment: CF API login does not pass Identity Provider origin

Tested with Provider Version
v1.6.1

Problem

The CloudFoundryEnvironment controller authenticates against the Cloud Foundry UAA using only username and password, without passing the Identity Provider origin. This causes authentication to fail with invalid_grant when the Service Account uses a custom Identity Provider.

The CF client is created in internal/clients/cfenvironment/cfenvironment.go:

cfv3config, err := config.New(url, config.UserPassword(username, password))

The Idp field from the Service Account secret is available in btp.Credential.UserCredential.Idp but is never passed to the CF client configuration. Without the origin login hint, the CF UAA cannot resolve the user against the correct Identity Provider.

This affects both code paths that create the CF client:

• createClient() (line 108) — used during Observe (DescribeInstance → getManagers)
• createClientWithType() (line 119) — used during Create (CreateInstance)

To Reproduce

1. Configure a ProviderConfig with a Service Account that uses a custom Identity Provider (with idp field set in the SA secret)
2. Create a CloudFoundryEnvironment CR
3. The controller attempts to log into the CF API without the IdP origin
4. CF UAA returns invalid_grant ("User authentication failed")
5. Both Observe and Create fail — the resource never becomes READY

Expected behavior
The controller should pass the Identity Provider origin from the Service Account secret to the CF client configuration, so that the CF UAA can resolve the user against the correct IdP.

Impact

This is a blocking issue: CloudFoundryEnvironment resources can never reach READY state when a custom Identity Provider is used. Unlike the related issue with hardcoded sap.ids for Org Managers (#505 ), this affects the controller's ability to interact with the CF API at all — no observation, creation, or deletion is possible.

Additional context
The Service Account secret already supports an idp field, and the Terraform setup builder (internal/clients/tfclient/setup.go:106-108) correctly passes it through for TF-based resources. The CF client setup does not follow the same pattern.