fix(sessions): truncate error_message in v0 StorageEvent to guard against VARCHAR(255) overflow

[STHITAPRAJNAS]

Fixes #4993.

Problem

DatabaseSessionService crashes on PostgreSQL databases that were created with an older ADK version where error_message was a VARCHAR(255) column. create_all() is additive-only — it never ALTERs existing columns — so those databases keep the narrow column indefinitely even after upgrading the package.

When a model returns a MALFORMED_FUNCTION_CALL error whose payload echoes back a large JSON body, the unbounded error_message string exceeds 255 characters and hits:

asyncpg.exceptions.StringDataRightTruncationError: value too long for type character varying(255)

This terminates the SSE stream entirely with no fallback and no warning to the caller.

Fix

Add a write-path guard in StorageEvent.from_event() (v0 schema only). If error_message exceeds the legacy column width it is clipped to 241 characters and suffixed with "...[truncated]", keeping the total at exactly 255. Messages within the limit are passed through unchanged.

The guard lives in the schema layer rather than the service layer so it is applied regardless of the call site, and it is scoped to v0 only because v1 stores everything in a JSONB event_data column and is not affected.

Two constants are introduced at module level with a comment explaining the invariant, so the magic number is traceable without digging into the issue history.

Permanent fix

Users on PostgreSQL with a legacy schema can resolve this at the DB level with:

ALTER TABLE events ALTER COLUMN error_message TYPE TEXT;

Or migrate to v1 fully via adk migrate session.

Testing

Added two unit tests to test_v0_storage_event.py:

• test_from_event_truncates_error_message_exceeding_varchar255 — a 300-char message is clamped to ≤ 255 chars and ends with the truncation suffix
• test_from_event_preserves_short_error_message — a short message is stored verbatim

[JiwaniZakir]

The test test_from_event_truncates_error_message_exceeding_varchar255 asserts len(...) <= _LEGACY_ERROR_MSG_MAX_LEN, but given the deterministic truncation logic in from_event, this should be a strict equality check (== _LEGACY_ERROR_MSG_MAX_LEN) — the weaker assertion would pass even if the truncation were accidentally off by several characters. There's also no test case for error_message=None, which exercises the falsy branch of the condition in from_event; while the logic looks correct, an explicit test would document the intent and prevent regressions. Additionally, the test file imports the private symbols _LEGACY_ERROR_MSG_MAX_LEN and _TRUNCATION_SUFFIX directly — if these ever need to be refactored or inlined, the test becomes a coupling point; consider asserting the concrete expected string ("x" * 241 + "...[truncated]") or at least the exact final length (255) to reduce that dependency.

[STHITAPRAJNAS]

Thanks for the thorough review @JiwaniZakir — all three points are valid, addressed in 9353950:

• Strict equality: changed <= _LEGACY_ERROR_MSG_MAX_LEN to == "x" * 241 + "...[truncated]" — the full concrete expected string, which also removes the need for the private symbol import
• Private symbol coupling: dropped the _LEGACY_ERROR_MSG_MAX_LEN and _TRUNCATION_SUFFIX imports; the test now asserts the exact output string directly
• None branch: added test_from_event_with_none_error_message to document and protect the falsy path through the guard