two migration errors (#224)

There were a few discrepancies between schemas and migrations introduced in #215 and #196. 
This ensures that the `supabase db diff` confirms equivalence.

Author: maparent

packages/database/supabase/migrations/20250619021503_correct_migrations.sql

@@ -0,0 +1,69 @@
+-- complete migration 20250610201801_create_access_table.sql
+
+revoke delete on table "public"."access_token" from "anon";
+
+revoke references on table "public"."access_token" from "anon";
+
+revoke trigger on table "public"."access_token" from "anon";
+
+revoke truncate on table "public"."access_token" from "anon";
+
+revoke update on table "public"."access_token" from "anon";
+
+-- rename in schema was not ported to migration 20250611180757_concept_upsert_functions.sql
+
+alter function "public".local_concept_to_db_concept(data concept_local_input) rename to _local_concept_to_db_concept;
+
+CREATE OR REPLACE FUNCTION public.upsert_concepts(v_space_id bigint, data jsonb)
+ RETURNS SETOF bigint
+ LANGUAGE plpgsql
+AS $function$
+DECLARE
+  v_platform public."Platform";
+  local_concept public.concept_local_input;
+  db_concept public."Concept"%ROWTYPE;
+  concept_row JSONB;
+  concept_id BIGINT;
+BEGIN
+  SELECT platform INTO STRICT v_platform FROM public."Space" WHERE id=v_space_id;
+  FOR concept_row IN SELECT * FROM jsonb_array_elements(data)
+  LOOP
+    -- first set defaults
+    local_concept := jsonb_populate_record(NULL::public.concept_local_input, '{"epistemic_status": "unknown", "literal_content":{},"reference_content":{},"is_schema":false}');
+    -- then input values
+    local_concept := jsonb_populate_record(local_concept, concept_row);
+    local_concept.space_id := v_space_id;
+    db_concept := public._local_concept_to_db_concept(local_concept);
+    BEGIN
+        -- cannot use db_concept.* because of refs.
+        INSERT INTO public."Concept" (
+        epistemic_status, name, description, author_id, created, last_modified, space_id, schema_id, literal_content, is_schema, represented_by_id, reference_content
+        ) VALUES (
+        db_concept.epistemic_status, db_concept.name, db_concept.description, db_concept.author_id, db_concept.created, db_concept.last_modified, db_concept.space_id, db_concept.schema_id, db_concept.literal_content, db_concept.is_schema, db_concept.represented_by_id, db_concept.reference_content
+        )
+        ON CONFLICT (represented_by_id) DO UPDATE SET
+            epistemic_status = db_concept.epistemic_status,
+            name = db_concept.name,
+            description = db_concept.description,
+            author_id = db_concept.author_id,
+            created = db_concept.created,
+            last_modified = db_concept.last_modified,
+            space_id = db_concept.space_id,
+            schema_id = db_concept.schema_id,
+            literal_content = db_concept.literal_content,
+            is_schema = db_concept.is_schema,
+            reference_content = db_concept.reference_content
+        -- ON CONFLICT (space_id, name) DO NOTHING... why can't I specify two conflict clauses?
+        RETURNING id INTO concept_id;
+        RETURN NEXT concept_id;
+    EXCEPTION
+        WHEN unique_violation THEN
+            -- a distinct unique constraint failed
+            RAISE WARNING 'Concept with space_id: % and name % already exists', v_space_id, local_concept.name;
+            RETURN NEXT -1; -- Return a special value to indicate conflict
+    END;
+  END LOOP;
+  RAISE DEBUG 'Completed upsert_content successfully';
+END;
+$function$
+;

packages/database/types.gen.ts

@@ -543,7 +543,7 @@ export type Database = {
           uid_to_sync: string
         }[]
       }
-      local_concept_to_db_concept: {
+      _local_concept_to_db_concept: {
         Args: {
           data: Database["public"]["CompositeTypes"]["concept_local_input"]
         }