PRR not immediately available after PackageRevision reports Ready

[efiacor]

Summary

When a v1alpha2 PackageRevision's Ready condition becomes True, the corresponding PackageRevisionResources (PRR) may not yet be queryable via the aggregated API. This creates a race condition where clients watching the PR status and then immediately fetching the PRR get a not found error.

Observed Behavior

1. PR controller reconciles a clone/copy/init operation
2. PR controller writes resources to the database and sets Ready=True on the CRD
3. Client sees Ready=True and calls porchctl rpkg pull (or any PRR GET)
4. Aggregated API returns packagerevisionresources.porch.kpt.dev "<name>" not found
5. After a short delay (1-3s), the PRR becomes available

Root Cause

The PR controller and the aggregated API server (which serves PRR) both read from the database, but there's no synchronization guarantee that the PRR is queryable at the moment the CRD status is updated. Possible causes:

• DB write for resources and CRD status update are not atomic
• Aggregated API server has its own cache/refresh interval
• The PRR handler queries the DB independently of the CRD status

Expected Behavior

When a PackageRevision reports Ready=True, the PRR should be immediately available via the aggregated API.

Workaround

E2E tests now poll for PRR visibility after waiting for Ready (see KubectlWaitForPackageRevisionReady in test/e2e/cli/cluster.go).

Suggested Fix Options

1. PR controller confirms PRR is queryable before setting Ready=True
2. Aggregated API ensures cache coherence with the DB write that triggers Ready
3. Add a ResourcesAvailable condition to the PR status that the aggregated API sets

Parent tracking issue: #811