feat: add optional Redis-backed local queue for later-phase background work

[maehwasoo]

Problem statement

Once the Python-first local backend baseline is in place, some longer-running tasks may benefit from optional async coordination instead of purely synchronous local execution.

Potential candidates include:

• indexing jobs
• evaluation jobs
• long-running agent runs with status polling
• short-lived cache entries for expensive repeated work

That need should be tracked separately from the baseline architecture work so the main direction stays focused and Redis remains an explicit follow-up decision.

Proposed solution

Add an optional Redis-backed local queue for later-phase background work.

Scope it narrowly:

• local-only
• single-user
• queue / ephemeral coordination / short-lived cache only
• never the source of truth for notes, index data, or final evaluation artifacts

Suggested implementation breakdown:

1. Reconfirm that synchronous local execution is no longer sufficient for the selected tasks.
2. Define the exact Redis responsibilities and non-responsibilities.
3. Add local startup/shutdown wiring for the optional Redis path.
4. Introduce queue-backed execution only for the selected long-running tasks.
5. Document operational tradeoffs, failure modes, and when Redis should remain disabled.

Follow-up relationship:

• This issue should be treated as a follow-up to feat: establish a Python-first local agent backend baseline #175.

Constraints / context (optional)

• Keep Redis optional, not mandatory for the baseline local architecture.
• Preserve the current explicit/gated write model for vault changes.
• Avoid turning the local stack into unnecessary multi-service complexity.
• Prefer queue/stream-oriented coordination over Pub/Sub-only delivery.