Add a way to retry imports that previously failed

[njakobsen]

Follow-up to #57, prompted by review of the host-side sweep in stolo_connect#1964: "Is there no mechanism in spatial_features or connect_engine that does this for us? This seems like a lot to reimplement to do something that should probably just be a single method call."

There wasn't, and the reviewer is right that there should be. FeatureImport::ClassMethods#update_features! covers bulk re-import, but nothing selects the records whose last attempt failed, and nothing queues the retry. So every host that wants to sweep them up writes the same three things by hand:

• the jsonb predicate for the failure status
• the iteration
• the choice to queue rather than run inline

The third is the one that bites. Calling #update_features! directly bypasses the SpatialProcessingJob callbacks that maintain spatial_processing_status_cache, so a record that imports successfully stays flagged as failed — and is picked up again by the next sweep. That was a real bug in the host-side task before this.

::with_failed_feature_updates and ::retry_failed_feature_updates! put all three in the gem that owns the status cache. Options pass through to the queued job, so a caller can lower the priority to keep a large sweep behind live uploads:

ReferralSubmission.retry_failed_feature_updates!(priority: 10)

Why here rather than Connect Engine

referrals and sites both carry spatial_processing_status_cache without including the engine's SpatialFeaturesDefaults concern, so anything defined there would silently miss them. The gem is where has_spatial_features and the status cache live, so every spatial model gets it regardless of which concern the host mixed in.

Verification

bundle exec rspec — 266 examples, 0 failures (19 pending, pre-existing). Three new examples cover the failure-only selection, that successes and never-imported records are left alone, and that options reach the queued job.

Deploying

3.11.1 — additive, no behaviour change to existing calls. connect_engine's ~> 3.11 constraint already admits it, so only the locks move.

Refs https://github.com/culturecode/stolo_connect/issues/1962

[njakobsen]

Opened #59 for the design question this raised: spatial_processing_status_cache is defined as queued-job state but read everywhere as last-import outcome, so an inline import that succeeds leaves a record flagged as failed permanently.

That's why ::retry_failed_feature_updates! here queues rather than importing inline — it's the only path that maintains the status honestly. It also means the sweep will over-select on hosts that import inline (stolo_connect's nightly geometry task does), picking up records that already recovered. They self-correct on the first run, but it's worth knowing before #59 is decided.