Update a reference table you own.

Passing items replaces them all. There is no merge and no way to add a single
item here; send the full list you want the table to have.

slug is immutable. Sending the value the table already has is a no-op, so a client
can PATCH back an object it just read; sending a well-formed but different value is a
400, because rule SQL names a table by slug and a rename would silently repoint
every rule that mentions the old name. A malformed slug is a 422 from validation
rather than a rename refusal -- the caller sent garbage, not a rename.

fields is read-only and simply ignored, which differs from slug on purpose:
it is derived, so a value sent for it means nothing, whereas a different slug is a
real request that has to be refused out loud. Replacing items re-derives fields;
a metadata-only PATCH leaves it alone. operation / grouping on an item are
likewise accepted and ignored.

visibility follows the same rule as create: public from any organization,
private from Nebulock only. Setting it on a curated table is what publishes or
unpublishes it for every tenant; on your own table it records a label and nothing more.

The items may arrive as a CSV instead. Send the request as multipart/form-data
with an optional payload field holding this JSON object and a file field
holding the CSV. Sending both items and a file is a 400.

items_mode=append adds the request's items to the stored ones instead of replacing
them, whichever way they arrived. A row the table already holds is skipped rather than
stored twice -- a duplicate changes nothing about what a rule matches and only consumes
the entry budget. The default is replace, so a caller that does not pass it sees
exactly the behaviour this route has always had. The size caps are checked against the
resulting table, not the request, so a table cannot be appended past its entry cap.

It may be sent as the ?items_mode= query parameter or as a field in the JSON
payload: a multipart upload already carries a payload part, and splitting one control
into the URL while the rest travels in the body makes the request harder to read than
it needs to be. Sending both is fine when they agree and a 400 when they do not,
because a client that disagrees with itself has not decided.

Every field_name written here is checked against the live events registry, so a
503 means that registry could not be reached rather than anything about your
request.