feat(postgres): support editing hstore columns

[arturbent0]

Reading hstore columns already worked (tokio-postgres decodes them natively as HashMap<String, Option>), but writing back failed with 'Cannot bind a JSON object to a non-JSON column' because hstore has no fixed OID and information_schema reports it generically as 'USER-DEFINED'.

• Resolve the real hstore OID per column via pg_type before binding, since it varies per installation/schema.
• Bind JSON objects (and, for now, JSON-encoded strings, the plain text cell editor doesn't yet distinguish hstore from other types) as HashMap<String, Option>, which tokio-postgres encodes natively as hstore.
• Expose udt_name on TableColumn so the frontend can identify hstore precisely; data_type alone can't, since it's shared with every other extension/custom type.
• Route hstore columns through the existing JSON editor in the row editor sidebar, and fix the inline cell editor to show valid JSON instead of '[object Object]' for any object-valued cell.

Closes #395

[NewtTheWolf]

Thanks for tackling this — resolving the per-install OID via pg_type and leaning on tokio-postgres's native HashMap encoding is the right approach, and the binding-layer test coverage is solid. 🙏

One blocking correctness issue inline: the USER-DEFINED fallback in the bind routing regresses editing of other user-defined types (enums, citext, PostGIS…). Fix + a note on the affected test are inline.

Non-blocking, your call:

• bind_pg_hstore duplicates the oid-resolve → hstore_map_from_json_object → Type::new → BoundValue block across the Object and String arms — could fold into a small local closure.
• get_hstore_oid_for_column fires one catalog query per USER-DEFINED column per row in the insert_record loop — fine for single-row edits, worth caching if bulk insert ever routes through here.
• Type::new(..., "public") hardcodes the schema; harmless since prepare_typed pins on the OID, just noting hstore can live in another schema.

Also: the branch currently has a merge conflict against main (mergeStateStatus: DIRTY) — could you rebase/resolve that when you get a chance? 🙏