feat(core-api): fallback to inline enrichment when event publishing fails

[sowndappan5]

Summary

This PR introduces a resilient dynamic fallback mechanism for memory enrichment scheduling. When inline_enrichment is disabled (deferred/async mode), any unexpected exception raised while publishing the event to the queue is caught and handled gracefully, falling back to synchronous inline enrichment. This guarantees memories are not left unenriched if the broker (e.g. Redis) is temporarily down or unreachable.

Related Issue

N/A (Direct Feature Enhancement)

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that changes existing behavior)
• Documentation update
• Refactor / internal cleanup
• Other:

How Has This Been Tested?

Created unit tests in tests/test_enrich_fallback.py covering both the successful async publishing path and the fallback path on publish exceptions.

Run command:

pytest tests/test_enrich_fallback.py

[sowndappan5]

Hi @Eldad-Caura and @erni-a,

Problem: In deferred mode, if the event broker is down, memory writes succeed but remain permanently unenriched.
What I did: Wrapped the publishing call in a try-except block to catch broker exceptions and fall back to inline enrichment, and added covering unit tests.
What it solves: Ensures data integrity by preventing memories from staying unenriched on broker/network failure.

My Evaluation (n=10):
Inline Mode (Sync): Avg Latency = 1206.93 ms
Deferred Mode (Async): Avg Latency = 0.11 ms (~11,000x faster under normal operation).

[sowndappan5]

Hi @Eldad-Caura,

Thanks again for reviewing and approving the PR. It looks like the required GitHub Actions workflows are still awaiting maintainer approval, so the CI and DCO checks haven't started yet.

Whenever you have a chance, could someone approve the workflows to run? Thanks!