fix(java,kotlin,python): derive the PK type from metadata instead of hardcoding it

The same bug in three ports: the generated API code hardcoded the primary-key type,
so an entity declaring `identity.primary @generation: uuid` got broken output while
its own DTO/model correctly used UUID. Not a metamodel gap — a missed reuse: every
port already had the type mapper and was already using it a few lines away.

The Kotlin generator even documented the assumption:
  "for v1 we just default to \"id\" : Long for the route signatures since the
   canonical Author/BaseEntity convention is a single Long PK."
It resolved the identity correctly, then threw the type away. Every entity in every
conformance corpus is a `field.long` increment PK, so no gate ever contradicted it.

- Java: `@PathVariable Long id` and `findById(Long id)` → Spring rejected a uuid path
  var with 400, and the generated repository interface was un-implementable against a
  UUID-keyed entity. New `SpringTypeMapper.primaryKeyJavaType()` (ADR-0039 resolving
  accessors) threaded through the controller (get/update/delete/M:N/TPH polymorphic +
  per-subtype) and the repository (findById/update/delete/M:N finder/TPH variants).
- Kotlin: WORSE — the generated code did not COMPILE. `@PathVariable id: Long` then
  `pkField eq id` against Exposed's `Column<UUID>` is a type error, and FK columns
  hardcoded `long("col").references(...)` so `Column<Long>.references(Column<UUID>)`
  broke the build for ANY relationship pointing at a uuid-PK entity. PK/FK types are
  now derived from the target's declared identity.
  Also found: the FR-009 filter coercer had no uuid arm, so `filter[id][eq]=<uuid>`
  would have ClassCastException'd at runtime; and TPH `writableFields` hardcoded the
  literal "id" when excluding the PK, wrong for any PK not named `id`.
- Python: the generated FastAPI router typed every path id `int`, so a real uuid was
  rejected with 422 by Pydantic and never reached the handler — the endpoint was
  simply unusable, and the cross-port contract (404 for a missing row) was broken.
  Now derives via the existing `type_map`, threaded through the repository Protocol,
  get/update/delete, M:N traversal and TPH routes. The generated router is booted over
  HTTP in a new test that proves 422 -> 404/200.

C# needed no change: it already derived the PK scalar and threaded it through every
route. It is the reference the other three were fixed against.

Gates: java-slow CI (full reactor + Java and Kotlin integration suites incl.
Testcontainers PG) green — Kotlin integration 98/98; codegen-spring 164/164;
codegen-kotlin 279/279 with no byte-drift on existing snapshots; Python 1422 pass.
A `field.long` increment PK still generates byte-identical output.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Hd5NWZ1rKau63vJzrBSpLb

Author: dmealing

server/java/codegen-kotlin/src/main/kotlin/com/metaobjects/generator/kotlin/KotlinExposedTableGenerator.kt

@@ -1076,7 +1076,7 @@ open class KotlinExposedTableGenerator : MultiFileDirectGeneratorBase<MetaObject
         val refSuffix = referentialActionSuffix(rel.onDeleteRaw, rel.onUpdateRaw)
         return FkColumnSpec(
             propertyName = propertyName,
-            columnExpr = "long(\"$colName\").references($targetTable.${primaryKeyProperty(target)}$refSuffix)",
+            columnExpr = "${fkColumnBuilder(target, colName)}.references($targetTable.${primaryKeyProperty(target)}$refSuffix)",
             refSuffix = refSuffix,
             declared = true,
             targetTable = targetTable,
@@ -1105,7 +1105,7 @@ open class KotlinExposedTableGenerator : MultiFileDirectGeneratorBase<MetaObject
         val refSuffix = referentialActionSuffix(rel.onDeleteRaw, rel.onUpdateRaw)
         return FkColumnSpec(
             propertyName = propertyName,
-            columnExpr = "long(\"$colName\").references($ownerTable.${primaryKeyProperty(owner)}$refSuffix)",
+            columnExpr = "${fkColumnBuilder(owner, colName)}.references($ownerTable.${primaryKeyProperty(owner)}$refSuffix)",
             refSuffix = refSuffix,
             declared = false,
             targetTable = ownerTable,
@@ -1231,6 +1231,28 @@ open class KotlinExposedTableGenerator : MultiFileDirectGeneratorBase<MetaObject
         return KotlinNaming.safeColumnProperty(pkField ?: "id")
     }
 
+    /**
+     * The Exposed column builder for a FK column pointing at [target]'s primary key.
+     * The FK column's SQL type MUST match the referenced PK's — Exposed's typed
+     * `Column<S : T>.references(Column<T>)` rejects a mismatch at compile time, so a
+     * hard-coded `long("author_id")` referencing a uuid PK broke the build of ANY
+     * relationship aimed at a uuid-keyed entity. Derived from the target's single-field
+     * `identity.primary` via [KotlinTypeMapper.exposedColumnSpec] (uuid → `uuid("col")`,
+     * long → `long("col")`, int → `integer("col")`, string → text/varchar), with the FK's
+     * own physical column name. Falls back to `long("col")` when the PK field can't be
+     * resolved — the historical default (same lossy-tolerant policy as
+     * [primaryKeyProperty]).
+     */
+    private fun fkColumnBuilder(target: MetaObject, colName: String): String {
+        // ADR-0039: resolving lookups — the identity and its field may be inherited.
+        val pkFieldName = target.getIdentities(true).firstOrNull { it.isPrimary }
+            ?.fields?.firstOrNull() ?: return "long(\"$colName\")"
+        val pkField = target.metaFields.firstOrNull { it.name == pkFieldName }
+            ?: return "long(\"$colName\")"
+        return runCatching { KotlinTypeMapper.exposedColumnSpec(pkField, colName) }
+            .getOrDefault("long(\"$colName\")")
+    }
+
     /** Read the `@column` attr on a relationship (inheritance allowed); null when absent. */
     private fun readColumnAttr(rel: MetaRelationship): String? {
         if (!rel.hasMetaAttr(CoreDBMetaDataProvider.COLUMN, true)) return null

server/java/codegen-kotlin/src/main/kotlin/com/metaobjects/generator/kotlin/KotlinRelationsGenerator.kt

@@ -138,6 +138,13 @@ open class KotlinRelationsGenerator : MultiFileDirectGeneratorBase<MetaObject>()
                 }
             }
             append("import org.jetbrains.exposed.sql.selectAll\n")
+            // java.util.UUID appears in helper signatures when the owner's PK (or a
+            // reverse-FK value type) is uuid — the param types were already derived, but
+            // without this import the generated file had an unresolved reference. Emitted
+            // conditionally so uuid-free files stay byte-identical.
+            if (pkParamSimpleName == "UUID" || reverseFks.any { it.valueType == "UUID" }) {
+                append("import java.util.UUID\n")
+            }
             append("\n")
             append("/** GENERATED — extension fns for `$ownerShort` to-many relationships. Do not hand-edit. */\n")
             var first = true
@@ -258,11 +265,12 @@ open class KotlinRelationsGenerator : MultiFileDirectGeneratorBase<MetaObject>()
     /**
      * Resolve the Kotlin type of [entity]'s primary key. Falls back to [LONG] when
      * the primary identity is missing, multi-field, or its field can't be resolved
-     * — Long matches the dominant convention (entities almost always have a single
-     * `field.long` PK; KotlinExposedTableGenerator's FK columns hard-code
-     * `long("…").references(...)`). Same lossy-tolerant policy as the table
-     * generator: defensive defaults rather than throwing on partially-formed
-     * metadata.
+     * — Long matches the dominant convention (a single `field.long` PK) and the
+     * same fallback KotlinExposedTableGenerator's FK column builder and
+     * KotlinSpringControllerGenerator's route signatures use, so the derived types
+     * stay in lockstep across the three generators. Same lossy-tolerant policy as
+     * the table generator: defensive defaults rather than throwing on
+     * partially-formed metadata.
      */
     protected open fun primaryKeyKotlinType(entity: MetaObject): TypeName {
         // ADR-0039: identities are inheritable — RESOLVE via getIdentities(true);