Recover stuck service operations after transient DB failures

[serdarozerr]

Problem

When CCDB becomes temporarily unreachable during a service broker polling cycle,
the polling job fails permanently even though the broker is still processing the
operation. This leaves the service resource in an inconsistent state:

• last_operation.state = 'in progress' (broker still working or already finished)
• pollable_job.state = FAILED (CC gave up)

Solution

Adds a new periodic scheduled job ServiceOperationsCreateInProgressCleanup that
detects stuck create operations whose polling job has permanently failed and
resolves them by marking the operation as failed and triggering orphan mitigation
to deprovision any broker-side resource, giving clients a definitive final state.

Detection chain:
service_instance/binding/key_operations.state = 'in progress'
AND type = 'create'
AND created_at within the max async poll window
→ JOIN service_instances/bindings/keys (via foreign key)
→ JOIN pollable_jobs (via resource_guid) WHERE state IN (POLLING, FAILED)
AND operation = 'service_instance/bindings/keys.create'
→ JOIN delayed_jobs (via delayed_job_guid) WHERE failed_at IS NOT NULL

Recovery:
Marks the stuck operation as failed, sets the pollable job to FAILED, and
calls OrphanMitigator to enqueue a broker-side DELETE for the potentially
orphaned resource. A row-level FOR UPDATE SKIP LOCKED guard prevents double
mitigation when multiple CC instances run concurrently.

Scope:
Covers service_instance.create, service_bindings.create, and
service_keys.create. Delete and update operations are intentionally excluded —
retrying a delete on the same resource GUID can cross-match with the old failed
pollable job, making safe recovery impossible without additional guards.

• Related links
  New Spec Parameter for Clock job capi-release#653

• I have reviewed the contributing guide

• I have viewed, signed, and submitted the Contributor License Agreement

• I have made this pull request to the main branch

• I have run all the unit tests using bundle exec rake

• I have run CF Acceptance Tests

[philippthun]

When focusing on failed jobs where the pollable job is still POLLING, this PR could be extended to all async operations:

service_instance.create, service_instance.update, service_instance.delete
service_binding.create, service_binding.delete
service_key.create, service_key.delete
service_route_binding.create, service_route_binding.delete

[jochenehret]

Looks good, just consider a lower job frequency.