fix: eliminate OOM in execution history trim under syslog load

[duguwanglong]

Under sustained syslog throughput, _trim_execution_history was called as a fire-and-forget background task every 5 messages per workflow. Each invocation called Storage.list_entries("workflow_execution/") which json.loads every execution record in the table into Python objects. Execution records included full alert payloads (resp_body, req_header, etc.) written by the dedup_and_write node, making each record several hundred KB. As the table grew to 3+ GB, a single trim scan materialised gigabytes of transient objects — py-spy confirmed 100% GIL time in json.raw_decode attributed to _trim_execution_history → list_entries. Because multiple trim tasks could be in flight simultaneously (one spawned per 5 messages, each taking tens of seconds to complete), the transient allocations multiplied, driving RSS to 20 GB without bound.

Fix:

• Storage.list_raw(): new method that returns (key, raw_value_str) pairs without any Python-side JSON parsing, compatible with all SQLite versions.
• _trim_execution_history: replaced list_entries + json.loads with list_raw + regex extraction of workflowId/startedAt from the first 400 bytes of each value string. Avoids constructing large Python objects entirely; regex on a 400-byte prefix is ~100x cheaper than full parse.
• _trim_in_flight: Set[str] guard ensures at most one trim task per workflow runs at a time, preventing concurrent scans from multiplying peak memory usage.