fix(batch): sync Batch application settings across code and deploy paths

[jQuinRivero]

Problem

Image-layer creation failed in a deployment environment before any task reached Azure Batch:

Code: InvalidPropertyValue
PropertyName:  registryServer
PropertyValue: <registry-name>.azurecr.io
Reason: The specified registry is an invalid docker registry server name

<registry-name>.azurecr.io is hastegeo's placeholder default — proof the real setting never reached the running app.

Root causes

1. AZURE_BATCH_REGISTRY_SERVER was read by code but emitted by nothing.

Surface	Variable
hastelib/src/hastegeo/core/config.py	reads AZURE_BATCH_REGISTRY_SERVER
.github/scripts/deploy_apps.sh	emitted AZURE_BATCH_REGISTRY_SERVER_URL
infra/modules/functions.bicep	emitted AZURE_BATCH_REGISTRY_SERVER_URL
local.settings.example.jsonc	emitted AZURE_BATCH_REGISTRY_SERVER_URL

AZURE_BATCH_REGISTRY_SERVER_URL was read by zero lines of Python. Because deploy_apps.sh re-sets the whole app-settings block on every run, a manual portal fix is clobbered by the next deploy.

2. deploy_apps.sh never emitted the shared-pool settings. The multi-tenant Batch pool work added five settings that functions.bicep sets but deploy_apps.sh — the script behind deploy-apps.yml — did not: AZURE_BATCH_{TRAINING,INFERENCE,IMAGERYPREP}_POOL_IDS, AZURE_BATCH_USE_SAS, AZURE_BATCH_MANAGE_POOLS. Environments deployed through it silently ran the legacy single-pool path against renamed pools. EMBEDDING_QUEUE_NAME was missing from both paths.

3. A reused Batch job stayed pinned to the pool that created it. Job ids default to the configured pool id, and create_job only re-enabled an existing job — it never re-pointed it. So capacity-aware spillover was silently ineffective, and once a pool was renamed or deleted, every task queued into a job bound to a pool that no longer existed.

Changes

Code

• config.py — resolve AZURE_BATCH_REGISTRY_SERVER, falling back to the deprecated _URL name and stripping any scheme (the Batch SDK wants a bare login server; the legacy setting stored a URL). Dual-read rather than a clean break, so existing deployments keep working until an operator renames the setting.
• new utils/batch_config.py — fail fast naming the unset application setting instead of surfacing an opaque Azure error from inside pool creation. Two tiers: registry settings are only required when AZURE_BATCH_MANAGE_POOLS is true, so environments on pre-created autoscale pools aren't broken.
• runners/azure_batch.py — validate at the submission boundary (add_task, not __init__ — the runner is constructed eagerly on read-only status paths); rebind a stale job/pool binding; whitelist both training and imageryprep images on created pools, matching batchPool.bicep.

Deploy paths

• deploy_apps.sh + deploy-apps.yml — emit the full setting set, with per-environment pool overrides that default to the previous behavior.
• functions.bicep (+ regenerated main.json), local.settings.example.jsonc.

Guard

• new check_env_drift.py + config-drift.yml — parses the code with ast to find every env read, classifies a variable as required when it has no default or its default is still a <placeholder>, and fails when a deploy path is missing it. Also reports the inverse (settings emitted but read by nothing) — the exact signature of a half-applied rename.

Verification

• The guard catches both root causes on pre-fix main (validated in a clean worktree): flags AZURE_BATCH_REGISTRY_SERVER and all three *_POOL_IDS, exit 1. Passes on this branch, exit 0.
• 13 new unit tests covering setting precedence, scheme normalization, placeholder validation (both tiers), and job rebinding. 101 passed, 7 skipped locally; the only non-passing modules need dev deps absent from my local env (pytest-mock, geopandas, shapely).
• pre-commit run clean on all changed files (black, isort, flake8, detect-secrets).
• az bicep build regenerates main.json; diff is the two intended settings plus generator-version churn.

Operator action required

Existing deployments should rename the AZURE_BATCH_REGISTRY_SERVER_URL application setting to AZURE_BATCH_REGISTRY_SERVER (value: bare login server, e.g. myacr.azurecr.io) on the api and queues Function Apps. The legacy name still works until then.

Also confirm AZURE_BATCH_TRAINING_POOL_ID / AZURE_BATCH_IMAGERYPREP_POOL_ID name pools that still exist and are identical across both apps — they double as the default Batch job ids, so a mismatch means the api app reads status from a job the queues app never wrote to.

Notes

• spec/features/batch-config-drift/ documents the root causes and design; cross-references batch-compute-expansion, whose deploy wiring was incomplete.
• Consolidating the two divergent deploy paths (deploy_apps.sh vs infra/main.bicep) is out of scope — tracked in spec/features/infra-iac-migration/.

[prbatero]

LGTM

[github-actions]

RC artifacts ready

All branch deployment references use the same RC tag:

• hastegeo_version: 1.0.27rc5
• training_image_tag: 1.0.27rc5
• imageprep_image_tag: 1.0.27rc5
• wheel: hastegeo-1.0.27rc5-py3-none-any.whl