chore(cloud-foundry): remove dead ngrx action classes with CF v2 API paths

[cweibel]

Summary

The ngrx runtime was removed as part of the Angular signals refactor. As a result, approximately 47 legacy ICFAction / PaginatedAction classes in src/frontend/packages/cloud-foundry/src/actions/ that carry raw CF v2 API path strings are now dead code — they are registered in entity catalog builder maps that are never invoked, and Store<T>.dispatch() is never called anywhere in the codebase.

These classes represent the full set of CF v2 API paths that were in use before the v3 migration. They should be removed to reduce maintenance burden, eliminate confusion about which API version Stratos uses, and make the codebase accurately reflect that all live frontend HTTP calls now go through the native v3 handlers at /pp/v1/cf/....

Affected files

All files are under src/frontend/packages/cloud-foundry/src/actions/:

File	Dead action classes	v2 paths carried
application.actions.ts	GetApplication, CreateNewApplication, UpdateExistingApplication, RestageApplication	apps/${guid}, apps, apps/${guid}/restage
app-metadata.actions.ts	GetAppStatsAction, GetAppEnvVarsAction, GetAppSummaryAction	apps/${guid}/{stats,env,summary}
application-service-routes.actions.ts	GetAppServiceBindings	apps/${guid}/service_bindings
organization.actions.ts	GetAllOrganizations, DeleteOrganization, CreateOrganization, UpdateOrganization	organizations[/${guid}]
space.actions.ts	GetSpace, GetAllAppsInSpace, CreateSpace, UpdateSpace, GetAllSpaceUsers, GetAllServicesForSpace, GetServiceInstancesForSpace	spaces[/${guid}/...]
app-event.actions.ts	GetAllAppEvents	events (v2-only; live path now uses /pp/v1/cf/audit_events/{cnsi} → CAPI v3 /v3/audit_events)
users.actions.ts	GetAllCfUsersAsAdmin, GetCfUser, ChangeCfUserRole, AddCfUserRole, RemoveCfUserRole	users[/${guid}], {spaces|orgs}/${guid}/${role}/...
service-instances.actions.ts	GetServiceInstance, DeleteServiceInstance, CreateServiceInstance, UpdateServiceInstance, ListServiceBindingsForInstance	service_instances[/${guid}], service_bindings
service-bindings.actions.ts	CreateServiceBinding, DeleteServiceBinding, FetchAllServiceBindings	service_bindings[/${guid}]
service.actions.ts	GetAllServices, GetService, GetServicePlansForService	services[/${guid}[/service_plans]]
service-plan.actions.ts	GetServicePlanServiceInstances	service_plan/${guid}/service_instances
service-plan-visibility.actions.ts	GetServicePlanVisibilities	service_plan_visibilities (v2-only flat-list; v3 replacement already at /pp/v1/cf/service_plans/{cnsi}/{planGuid}/visibility)
user-provided-service.actions.ts	GetAllUserProvidedServices, GetUserProvidedService, DeleteUserProvidedInstance	user_provided_service_instances[/${guid}]
quota-definitions.actions.ts	GetSpaceQuotaDefinition, AssociateSpaceQuota, DisassociateSpaceQuota, CreateQuotaDefinition, UpdateQuotaDefinition, DeleteQuotaDefinition, CreateSpaceQuotaDefinition, UpdateSpaceQuotaDefinition, DeleteSpaceQuotaDefinition	quota_definitions[/${guid}], space_quota_definitions[/${guid}[/spaces/${guid}]]

Notes

• Two action classes have // FLAG (A6) comments explicitly noting their v2-shaped request bodies (CreateNewApplication, CreateSpace) — these were intentionally flagged during the write-path migration as needing cleanup.
• service_plan_visibilities is a v2-only endpoint with no v3 flat-list equivalent; the backend already implements the v3 per-plan path.
• GetAllAppEvents targets the v2 /events endpoint; the live replacement is CnsiAuditEventsSource → /v3/audit_events.
• The entity catalog builder maps that reference these action classes should be audited as part of this cleanup — some map entries may also be removable.
• IUserProvidedServiceInstanceData (an interface, not an action class) is still imported in two active files and should be kept or migrated to an appropriate types file before removing user-provided-service.actions.ts.

Acceptance criteria

• All dead action classes listed above are removed.
• Entity catalog builder maps no longer reference the removed classes.
• IUserProvidedServiceInstanceData interface is relocated to a types file if still needed, or removed if unused.
• No live code paths are broken (verify with existing test suite).
• FLAG (A6) comments are resolved.

[norman-abramovitz]

I am still trying to decide how to handle v2 only (people do not upgrade), v2/v3 side by side, and v3 only.
To get the V3 work done, I took the approach of V3 only and V2 only. The middle has not been done. I left the dead ngrx code to remember what still needs to be done to handle V2/V3.

What is your take on handling V2/V3? @cweibel
The only decision was the conversion signals

[cweibel]

I don't think people can opt out of CAPI v3 at this point, only whether they continue to support CAPI v3 on the cloud controller. If stratos works solely off of CAPI v3 that feels like the correct current and future path