fix: persist on_event_callback mutations before session append

[Jholly2008]

Please ensure you have read the contribution guide before creating a pull request.

Link to Issue or Description of Change

1. Link to an existing issue (if applicable):

• Closes: on_event_callback executes after append_event, preventing plugin modifications from being persisted #3990

2. Or, if no issue exists, describe the change:

Problem:
Runner._exec_with_plugin() appended events to the session before running on_event_callback(). When a plugin returned a modified event, the client received the modified event but session storage still contained the original one.

Solution:
Run on_event_callback() before persistence and append the final event that will actually be yielded. This keeps streamed events and stored session history consistent, including the live-mode buffered event path. A regression test now verifies that the callback-modified event is persisted.

Testing Plan

Unit Tests:

• I have added or updated unit tests for my change.
• All unit tests pass locally.

Passed locally:

• .\\.venv\\Scripts\\python.exe -m pytest tests\\unittests\\test_runners.py -q
• Result: 39 passed

Manual End-to-End (E2E) Tests:

• Not run. This is a backend session-persistence fix covered by unit tests.

Checklist

• I have read the CONTRIBUTING.md document.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.
• I have manually tested my changes end-to-end.
• Any dependent changes have been merged and published in downstream modules.

Additional context

• The change preserves the existing append/no-append decisions and only changes which event object is persisted.
• Buffered live events now go through the same callback-before-persist flow as non-buffered events.

[JiwaniZakir]

The refactor to _process_event correctly fixes the ordering bug, but there's a subtle behavioral change worth noting: buffered events in the live transcription path now flow through run_on_event_callback (via _process_event), whereas the original code only called append_event on them and yielded them directly without invoking any callbacks. If this is intentional, it should be covered by a test—currently test_runner_modifies_event_after_execution only verifies the non-buffered path. A test that enables buffering and verifies callback application (or non-application) on buffered events would make the intended semantics explicit.

Additionally, in the transcription-finished branch, _apply_run_config_custom_metadata is called on the original event before _process_event is called, and then _process_event calls it again on modified_event if the callback returns one. Since modified_event comes from model_copy, this double application is harmless, but it's easy to miss during future modifications; a brief comment inside _process_event noting that _apply_run_config_custom_metadata may have already been applied to the unmodified event would reduce confusion.

The test change from constructing a bare Event(invocation_id="", author="", ...) to event.model_copy(deep=True, update={...}) is strictly correct—the old approach would have produced an event missing fields like invocation_id and actions, which makes the persisted-event assertion added in the test (session.events[1]) fragile against schema changes.

[rohityan]

Hi @Jholly2008 , Thank you for your contribution! We appreciate you taking the time to submit this pull request. Your PR has been received by the team and is currently under review. We will provide feedback as soon as we have an update to share.

[rohityan]

Hi @ankursharmas , can you please review this.