Bound row_binding_id and credential_ref to 255 characters like the AdCP identifiers #1498

Problem

#1485 renamed the stored object locators to AdCP's names and bounds (object_ref and native_version_ref, 1 to 1024 characters). Two adopter-chosen identifiers in the same layout keep a 128-character bound that nothing in AdCP uses: row_binding_id (in the DDL and in Python) and credential_ref (Python only). Every comparable AdCP identifier (reporting_revision_id, resource_ref, destination_ref) uses ^[A-Za-z0-9_.:-]{1,255}$. An adopter who derives binding IDs from AdCP destination references can exceed 128 and be refused for no protocol reason. This is a shared-DDL change, so it needs the JS SDK to make the same change.

Evidence

All references are to main at 47084e83a; the JS SDK is adcp-client main at 7c7f730f4.

• src/adcp/reporting/ledger/reporting_row_storage.sql:110:

  row_binding_id TEXT COLLATE "C" PRIMARY KEY CHECK (row_binding_id ~ '^[A-Za-z0-9_.:-]{1,128}$'),

• src/adcp/reporting/ledger/row_storage.py:108-109:

  _BINDING_ID = re.compile(r"^[A-Za-z0-9_.:-]{1,128}$")
  _CREDENTIAL_REF = re.compile(r"^[A-Za-z0-9_.:-]{1,128}$")

• adcp-client src/lib/reporting/ledger/row-storage-migration.ts:92: the same {1,128} check.

• AdCP static/schemas/source/core/reporting-revision.json: reporting_revision_id pattern ^[A-Za-z0-9_.:-]{1,255}$.

Suggested fix

Change the three bounds to {1,255} in the same guarded-rename migration style #1485 used (an ALTER TABLE ... DROP CONSTRAINT / ADD CONSTRAINT pair, idempotent), and make the matching change in row-storage-migration.ts. Widening a CHECK needs no data migration.

Introduced in #1464.