Race in ParserService::setNextAttempt() causes duplicate primary key on weather_forecast_information under concurrent requests

Problem/Motivation

When forecast download fails or the module defers the next attempt, ParserService::setNextAttempt() updates weather_forecast_information by deleting the row and then always calling create() (INSERT). Under concurrent requests (e.g. homepage with weather, load tests, Big Pipe, crawlers), two workers can both pass load(), both delete, then both INSERT the same geoid, triggering:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '…' for key 'weather_forecast_information.PRIMARY'

Example stack: ParserService::setNextAttempt() → EntityBase::save() on INSERT.

Steps to reproduce

1. Ensure a weather_forecast_information row exists for a place (e.g. geonames_703448).
2. Drive traffic to a route that renders weather so ParserService::getWeather() / downloadWeather() runs while the next download is due but the remote forecast request fails (or forecast is treated as stale so setNextAttempt() runs).
3. Run many concurrent requests against that path for several minutes (e.g. JMeter: 200 threads, ramp-up 60s, duration 1800s against an environment with weather on the page).

Actual: Intermittent 1062 duplicate key on INSERT for the same geoid.

Expected: Next download attempt metadata is persisted without duplicate-key errors under concurrency.

Proposed resolution

Align setNextAttempt() with the same pattern already used in parseForecast(): load the entity; if it exists, set fields from $meta and save() (UPDATE); otherwise create() and save(). Do not delete then insert. WeatherForecastInformationInterface is already imported in ParserService.php.

Patch attached: weather-setnextattempt-avoid-duplicate-key.patch (applies to 3.0.0-alpha1 src/Service/ParserService.php; verify reroll against active 3.0.x if needed).

Remaining tasks

• Review and commit the patch (or request reroll if default branch differs from alpha1).
• Optionally add automated or manual concurrency/load note in module docs or change record if maintainers want it documented.

User interface changes

None.

API changes

None.

Data model changes

None. Same table and keys; only how rows are written changes (UPDATE instead of DELETE+INSERT for the existing case).