I34 controlled startup

[QSparks]

Previously, a pull or redeploy could start all Swarm services at roughly the same time because Swarm does not use depends_on for readiness.
The importer can take time to populate the DB, so some downstream containers would fail to start and exhaust their max_attempts before upstream services were ready.
This would often require a full stop/pull/start cycle.

The new flow makes startup and redeployment deterministic:

• Redeploying with the same CHYP_IMPORT_ID skips the import if it already completed.
• A new import builds separate staging tables while the current dataset stays available.
• Once the import finishes, the new dataset replaces the old one in a single database transaction.
• BBOX waits for the matching import to finish before starting.
• The app and Varnish wait for BBOX to serve that exact import.
• Varnish starts with an empty tile cache only after the new dataset is ready.
• Health checks keep the existing reader tasks serving until the replacements are ready.
• If an import is interrupted, the next importer removes the incomplete staging tables and retries without affecting the live dataset.
• After a Swarm or node restart, each service performs its own readiness checks instead of relying on container startup order.

Normal Portainer Pull and redeploy should now be able to replace services without manually stopping the whole stack first.

PostGIS uses stop-first when it is replaced, but the database remains on shared persistent storage.
If PostgreSQL crashes during the final swap, the database should contain either the previous dataset or the fully committed new dataset, not a partially published state.

Resolves #34

[Nospamas]

Approved, but comment.

[Nospamas]

For consistency with other parts of this stack is it worth considering moving this statup logic into bash and running it before starting the server proper?