feat: add table-references command group

[andrewchester-dm]

Adds a table-references command group (list/get/create/update/delete) to dm, mirroring the existing connections command group, over `datamasque-python TableReferenceClient.

• create accepts --file (JSON) or flags for the common case; source is a file path for file connections or schema.table for database connections, with format always explicit, never inferred.
• update changes only the fields passed; any CSV/format flag replaces options wholesale on the resulting PUT.
• A 404 from a server that predates table references surfaces as "not supported by this DataMasque version" rather than a generic failure.
  Bumps the datamasque-python floor to >=1.2.5,<2.

[ClassicMMT]

Good job looks great!

Left a few small comments of things to look into.

Please make sure you add a PR description and bump dm-python to >=1.2.5.

[ClassicMMT]

Looking good. Almost there!

[ClassicMMT]

Approved. Just two last things left to make it look a bit better.

[andrewchester-dm]

Tests I ran

• create --name customers with missing flags → confirmed clean usage error

• create --name customers --connection test_files --source ... → success

• get customers --json → confirmed all defaults filled in correctly

• list → confirmed table rendering

• create --file /tmp/orders.json → success, get orders --json → confirmed

• delete orders / delete customers (with y/N prompt) → both correct

• Repeated create --name test_files ... three times → confirmed create-or-update (idempotent overwrite), no "duplicate name" error

• update test_files (no fields) → confirmed "pass at least one field" error

• connections create throwaway → connections delete throwaway → table-references create --connection throwaway → got "not found" (the flag-path limitation we then investigated and logged)

• update test_files --delimiter ';' → confirmed full-replace-not-merge behavior

• Malformed --file ({"name": "bad"}) → confirmed clean error, no traceback

• get/update/delete on a nonexistent name → confirmed clean "not found" on all three

• --connection by UUID (flag form) → confirmed equivalent to name form

• --file combined with another flag → confirmed rejection, confirmed target record unchanged

• Archived-connection rejection via --file (raw ID, throwaway2) → confirmed real server message: "Cannot reference an archived connection."

• Cleaned up all test clutter, then real Postgres connection (library db) + dm connections test → confirmed live reachability

• Table reference against real schema.table source (public.details), then update to public.drivers license → confirmed DB-connection path works

• Unsupported connection type (real MongoDB connection object) → confirmed clean rejection

• "Not supported by this DataMasque version" (temporarily disabled the URL route, confirmed 404→clean CLI message, reverted) → confirmed

• TREF011 JSON-side masking run — first attempt failed (later traced to a stale build cache on my end, not a real bug; rebuilt fresh and re-ran successfully)

• TREF011 DB-side masking run against a real local Postgres I set up — first comparison against the JSON side mismatched (traced to independent per-run random salts, not a bug); re-ran both sides with a shared run_secret → confirmed byte-identical masked output across both engines (the actual cross-system consistency guarantee)

• TREF012 (NDJSON, independent per-record resolution) → confirmed same-canonical records mask alike, others don't collide

• TREF013 (JSON on_missing: error) → confirmed exact error text, whole-task failure

• TREF014 (JSON on_missing: self) → confirmed deterministic self-seed, warning logged exactly once

• TREF017 (table_reference + force_consistency: true) → confirmed rejected at prepare time, exact error text

• TREF019 (null source_key canonicalization) → confirmed nulls mask alike, non-null miss doesn't collide

• TREF021 (string "800" vs number 800 key equivalence) → confirmed identical resolution

• TREF022 (object source_key) → confirmed rejection, exact error text

• TREF023 (array source_key) → confirmed rejection, exact error text

• Verified all 6 GitHub Actions CI checks green on the final pushed commit

[ClassicMMT]

Looks good to me. @kw-datamasque all good?

[ClassicMMT]

Looks good to me. @kw-datamasque all good?

[kw-datamasque]

Feel free to create a new release once merged in!