refactor: increase varchar sizes for event related fields

[chenyme]

Summary

Fix chat run event persistence failures caused by overly short event identifier columns.

When providers such as Grok return native web search / server-side tool events, their external tool call IDs can exceed the previous varchar(64) / varchar(96) limits in chat_run_events. This could make event recording fail and interrupt generation with value too long for type character varying(64).

This change expands the affected chat run event fields and adds startup schema migration for existing deployments.

Change type

• Bug fix
• Feature
• Documentation
• Refactor
• Configuration / deployment
• Security hardening
• Other

Affected areas

• Frontend / UI
• Backend / API
• Authentication / authorization
• Conversations / streaming
• Files / RAG / extraction
• Model routing / providers
• MCP / tools
• Billing / payments
• Admin console
• Deployment / Docker / configuration
• Documentation

Verification

• cd backend && go test ./internal/infra/persistence/postgres/conversation/... ./internal/infra/persistence/models/... ./internal/application/conversation/...
• git diff --check

Screenshots, API examples, or logs

Reported error:

ERROR: value too long for type character varying(64) (SQLSTATE 22001)

Triggered while inserting into chat_run_events for native web search / server-side tool event records.

Configuration, migration, and compatibility notes

Adds startup schema migration for existing databases:

• chat_run_events.event_id: varchar(255)
• chat_run_events.parent_event_id: varchar(255)
• chat_run_events.title: varchar(255)
• chat_run_events.tool_call_id: varchar(255)

No API contract or configuration changes.

Documentation

• Documentation is not needed for this change.
• Documentation was updated.
• Documentation still needs to be updated.

Security and privacy

• No secrets, tokens, credentials, local config, or personal data are included.
• User data access remains scoped by authenticated user context unless an admin-only path explicitly requires broader access.
• Security-sensitive behavior was reviewed, including authentication, authorization, provider routing, file processing, billing, and admin APIs where relevant.

Checklist

• I searched existing issues and pull requests.
• Changes are focused and do not include unrelated refactors.
• Tests or static verification were run where practical.
• User-facing behavior, deployment steps, API contracts, or configuration changes are documented.
• Generated artifacts are included only when this project explicitly requires them.
• Caches, build output, .pyc files, .env files, and local storage data are not committed.