Fix jobs table generation for uuid FK-derived primary keys (#1515)

[dimitri-yatsenko]

Fixes #1515.

Problem

Accessing .jobs on a Computed/Imported table whose primary key is FK-derived from a uuid attribute crashed with:

DataJointError: Unsupported attribute type binary(16)

This fires on the first .jobs access for such a table — including the implicit access inside populate(reserve_jobs=True) — and never recovers, since the ~~jobs table stays undeclared. It disables reserve_jobs=True entirely for the common, recommended pattern of using uuid root keys with downstream computed tables.

Root cause

Job._generate_definition() builds the ~~jobs table's DataJoint definition string from the target's FK-derived primary key. For each attribute it emitted attr.type — the backend-resolved SQL type (binary(16) for a uuid) — rather than the DataJoint-level alias the user wrote (uuid). binary(16) is not valid DataJoint definition syntax, so when Job.declare() re-parsed the generated string, match_type("binary(16)") matched no pattern and raised.

Fix

Use attr.original_type or attr.type in _get_fk_derived_pk_attrs, mirroring the fallback DataJoint already uses in heading.py (original_type = attr["original_type"] or attr["type"]). original_type holds the DataJoint alias for core types (uuid, float32, …) and is None otherwise, so:

• uuid PK → definition line item : uuid (re-parses correctly; DataJoint resolves it back to binary(16) internally).
• any other core-type alias in an FK-derived PK is fixed the same way, not just uuid.
• non-alias types are unaffected (fall back to attr.type as before).

Test

Adds test_jobs_table_uuid_fk_derived_pk (plus a BasicComputed table in the uuid test schema: a Computed table whose PK is FK-derived from a uuid parent). It asserts the generated definition carries uuid (not binary(16)), that .jobs.refresh() declares the table, and that the PK attribute round-trips to original_type == "uuid".

[MilagrosMarin]

LGTM.

Small strengthening: the fix mirrors the same original_type or type fallback in TWO existing sites — heading.py:543 AND table.py:1327 (inside Table.describe). Worth mentioning the second precedent in the PR body — reinforces "jobs.py was the outlier missing the pattern" rather than "one-off similarity".

Optional hardening: test uses uuid only, but the fix generalizes to any core-type alias. A parameterized second case (e.g., decimal(6,3) PK) would catch a hypothetical mis-regression like if original_type == "uuid": ... else: attr.type. Non-blocking — the fix generalizes by construction (the or short-circuit applies to any attribute whose original_type is set).