Cap plugin revision ids at the 32 chars MySQL stores

Rolling the containers failed on strict MySQL: the endpoints chain could not
stamp its new head with "Data too long for column version_num". Plugin version
tables declare version_num VARCHAR(32) and the new revision id was 33 chars.

Nothing in the suite caught it. The tests run on SQLite, which does not enforce
declared column widths, so an over-long id passes locally and fails only on a
real deploy - after the migration body has run and only the stamp fails. The
rollback was clean here, but the failure lands at the worst possible point.

Shorten the id and assert the limit in the test that already parses every
plugin revision, so the next over-long id fails on a laptop instead of during
a roll. Core is deliberately not covered: its alembic_version is VARCHAR(128),
and it already carries ids longer than 32 that are correct.

plugins/endpoints/migrations/versions/0019_split_shipped_monitor_policies.py

@@ -39,7 +39,7 @@ Idempotent on the policy names, so a re-run neither duplicates the split rows
 nor resurrects the bundle. Guards on the policy tables being present and no-ops
 if they are not, matching 0007.
 
-Revision ID: endpoints0019splitmonitorpolicies
+Revision ID: endpoints0019splitpolicies
 Revises: endpoints0018endpointlocks
 """
 from alembic import op
@@ -49,7 +49,9 @@ import sqlalchemy as sa
 from datetime import datetime
 
 
-revision = 'endpoints0019splitmonitorpolicies'
+# Alembic stores this in alembic_version.version_num, a VARCHAR(32). A longer
+# id passes on SQLite and fails on strict MySQL with "Data too long".
+revision = 'endpoints0019splitpolicies'
 down_revision = 'endpoints0018endpointlocks'
 branch_labels = None
 depends_on = None