Table dialog: "Data type" dropdown in the expanded Definition tab shows all types, ignoring the allowed-type restriction applied inline

[VIBVEL47]

Describe the bug

In the Table Create/Properties dialog, the Columns grid exposes the "Data type" field through two editors that present inconsistent option lists for the same column:

• The inline grid-cell "Data type" dropdown correctly applies the allowed-type restriction. For an existing column it offers only the types the column can be altered to (the edit_types subset).
• The expanded row's Definition tab "Data type" dropdown offers the full superset of types, ignoring the restriction — so it lets you pick types the column cannot be changed to.

Both editors are backed by the same cltype field, so they should offer the same list. In practice they disagree: the inline cell is filtered (correct), the Definition-tab control is unfiltered (wrong).

Root cause (shared SchemaView code, so this is upstream pgAdmin, not distro-specific):

• The cltype field defines the same edit_types filter for both its cell (inline) and type (form) editors. The filter only applies when the column is not new: if (!isNew(state) && !inErd) { filter to edit_types }.
• For the inline cell, the filter receives the row's data (with cid, attnum, edit_types), so isNew() correctly returns false and the list is filtered.
• For the expanded Definition-tab control, MappedFormControl evaluates the field's type(state) callback with state = schemaState.data — the root (table) data, not the field's containing row. That root object has no cid/attnum/edit_types, so isNew() returns true, the filter is skipped, and the full list is shown.
  • web/pgadmin/static/js/SchemaView/MappedControl.jsx (MappedFormControl): const state = schemaState.data; then evalFunc(null, field.type, state).
  • It should evaluate against the object that contains the field (the field's parent accessPath) — which is the root for a top-level field, and the row object for a nested collection form.

To Reproduce

Steps to reproduce the behavior:

1. Connect to a PostgreSQL server and create a table with at least one column, e.g.:

   CREATE TABLE public.t_types (c1 integer);

2. Right-click t_types → Properties → Columns tab.
3. On the existing column c1, open the Data type dropdown directly in the grid cell → note the limited (restricted) list of types.
4. Click the edit (pencil) icon to expand the same row, go to the Definition tab, and open the Data type dropdown there → note the much larger, unrestricted list.
5. The two lists disagree for the same column.

Expected behavior

Both "Data type" dropdowns (inline grid cell and the expanded Definition tab) present the same list for a given column — i.e. the expanded Definition-tab control applies the same edit_types restriction as the inline cell for an existing column, and both show the full list for a new column.

Error message

No error is thrown — this is a silent inconsistency. It is visible via the field callback receiving the wrong state: in the expanded form the cltype filter sees isNew = true and edit_types = [] (because it is handed the root/table data), so it returns all types; the inline cell sees isNew = false with the real edit_types and returns the restricted subset.

Screenshots

Compare, for the same existing column, the inline grid-cell "Data type" dropdown (restricted list) against the expanded Definition-tab "Data type" dropdown (full list). (Attach both dropdowns open side by side.)

Desktop

• OS: macOS
• pgAdmin version: 9.16
• Mode: Server
• Browser (if running in server mode): Chrome
• Package type: Python (running from source)

Additional context

• Affected area: shared SchemaView form control — web/pgadmin/static/js/SchemaView/MappedControl.jsx (MappedFormControl), which evaluates every field's type(state) callback against the root data instead of the field's containing object. This affects any nested collection form whose field type/other callbacks depend on sibling values in the same row (the Table → Columns "Data type" editor is the visible case).
• Fix direction: evaluate field.type against schemaState.value(accessPath.slice(0, -1)) (the containing object). For a top-level field this equals the root data (unchanged behavior); for a nested row it correctly resolves to the row's data.