Point thread and task indicator columns at modelcatalog_standard_variable

[mosoriob]

Fixes the Variables step of the thread wizard, which cannot save any indicator.
See mintproject/monorepo#106.

The defect

VariablesStep writes a standard variable id — a URI such as
https://w3id.org/okn/i/mint/DRAWDOWN — to thread.response_variable_id.
The foreign key referenced public.variable, whose ids are bare CSDMS-style
names such as drawdown. At TACC 0 of 668 standard variable ids are a valid
variable.id, so every save failed:

ApolloError: Foreign key violation. insert or update on table "thread"
violates foreign key constraint "thread_response_variable_id_fkey"

Why the constraint moves, not the client

The read side already keys on standard variable ids (ModelsStep, the picker
itself). public.variable is frozen — etl/load.py writes modelcatalog_*
tables only, and nothing has written variable since the DYNAMO migration — so
mapping the client onto it would tie the feature to a table that cannot grow.

What the migration does

• Drops the four indicator constraints (thread and task × response and
  driving), migrates the data, then re-adds them against
  modelcatalog_standard_variable. The drop comes first because the old
  constraint refuses the new ids.
• Maps existing values by label, the only bridge between the two id schemes.
  A value maps only when exactly one standard variable carries that label;
  62 labels are shared by up to 6 standard variables, so those are nulled rather
  than guessed. A wrong id shows a silent No models found.; a null shows the
  step as unset.
• Moves the four variable array relationships to
  modelcatalog_standard_variable. Without this the migration leaves four
  inconsistent metadata objects — observed live, see below.

Verified on the MicroK8s dev cluster

Seeded four cases, ran up.sql, then down.sql, then up.sql again:

stored value	after up.sql
air__daily_max_of_temperature (unique label)	.../AIR__DAILY_MAX_OF_TEMPERATURE
soil_water__volume_fraction (2 standard variables)	NULL
crop__planting_end_time (no standard variable)	NULL
total_water_storage (the one real row)	.../TOTAL_WATER_STORAGE

All four constraints report confrelid = modelcatalog_standard_variable.
down.sql restores the mapped values to their labels and the constraints to
public.variable; values that up.sql nulled stay null, which is lossy by
construction and documented in the file.

Metadata after the migration and the relationship move:
get_inconsistent_metadata → is_consistent: true. thread.response_variable
resolves to modelcatalog_standard_variable and returns the label. Writing a
URI now succeeds; writing the bare drawdown is now the one refused.

Data cost

At TACC one row: thread nzGQkhtRsudfSEHkDGct, whose total_water_storage
maps uniquely. No task carries either column. ISI is unmeasured, which is why
the mapping exists rather than a blanket null.

Follow-up, not in this PR

The Ensemble Manager validates response_variables against the variable table
on POST /v1/problemStatements/*/subtasks (subTasksService.ts:209,219). After
this lands that route rejects standard variable URIs. ui-react does not call
it — it writes threads through Hasura. Filed separately.