graphql_engine: grant update on the two junction tables that carry a payload column

[mosoriob]

Not a blocker. Do this only when the trigger below occurs.

What

Two junction tables carry a payload column. Neither grants update to role user.

table	payload column
modelcatalog_configuration_input	is_optional
modelcatalog_diagram_part	part_type

The other ~22 junction tables are pure FK pairs. They need no update permission.

Why the metadata looks wrong

CLAUDE.md gives the rule. FK-pair-only junctions get insert and delete. Entity tables get full
CRUD. These two tables are neither. They are junctions with an attribute. The rule has no case
for them, so they fell into the junction bucket.

Why it is not urgent

Clients change these columns by delete-then-insert. See monorepo#91 and monorepo#93.

• An upsert and a delete-then-insert are both one request in one transaction. Speed and
  correctness do not change.
• Security does not change. Role user already holds delete with filter: {} and insert with
  check: {}. A user can already get the same result.
• The gain is only semantic. An update says the attribute changed. A delete-then-insert says the
  relation ended and a new one began. The second statement is false.

The trigger to act

Act when a modelcatalog_* table gets created_at, created_by, or row-level security. See
ADR-0001 for that debt.
Delete-then-insert resets such columns. The fault is silent.

The change

1. Grant update on the non-key columns of both tables. Do both in one change.
2. Change the client mutation back to an upsert. Run codegen.
3. Apply the metadata on every deployment, TACC included.

Step 3 is the cost. It is why this waits.