Reuse the configured plugin-framework provider across reconciles instead of re-configuring on every Connect

## What problem are you facing?

The no-fork plugin-framework connector re-runs the provider's `Configure` step on every reconcile of every managed resource. It builds a fresh provider server, runs `Configure`, uses it for that one reconcile, and discards it. crossplane-runtime calls `Connect` once per reconcile, so nothing is reused across reconciles. The async framework connector delegates to the same path, so it behaves identically.

For a provider that authenticates in `Configure` (SAP BTP logs in there), that means one login per operation. The result is a ~1:1 login/request ratio and steady auth load on the upstream API. SAP/crossplane-provider-btp#702 tracks the downstream impact.

## How could Upjet help solve your problem?

Configure a provider once per credential set and reuse it. The SDKv2 path already does this. The provider's `SetupFn` builds the configured handle and hands it to upjet on `terraform.Setup.Meta`; every operation reuses it and `Connect` never re-runs `Configure`. The framework path has no equivalent slot. `Setup.FrameworkProvider` is the unconfigured provider, so upjet configures and discards it each Connect, because the provider has nowhere to pass a configured server.

Give the framework path the same escape hatch: a `Meta`-equivalent slot on `terraform.Setup` for a configured framework provider server. When `SetupFn` populates it, upjet uses it as-is instead of building from `FrameworkProvider`; `Configure` then runs only when the provider decides to build a new one.

That decision is the provider's, keyed on the resolved provider configuration. Resources that resolve to the same config share a server; resources that resolve to different config (different credentials, endpoints, or target accounts) each get their own, so no session leaks across them. A provider that must reconfigure per resource leaves the slot empty and keeps today's behavior, making the change backward compatible.

Invalidation would be the provider's responsibility, but upjet should define what happens when a cached server hits an auth-class error mid-operation: automatically reconfigure or push the error back to the provider.

Start at the framework connector's Connect path and the terraform.Setup, SetupFn, and Setup.FrameworkProvider entry points; compare them with the SDKv2 setup path that stores a configured handle in terraform.Setup.Meta. Define how a configured framework provider server is reused per provider configuration, how empty slots preserve current behavior, and how auth-class errors are handled; done means the reuse and backward-compatible cases are specified and covered by tests.

Written by the indexing model from the issue text.