Design CI lanes for layered test execution

[darthfork]

Parent issue: #52

Summary

Define how unit, integration, Redis-backed, and system tests run in CI so we get better confidence without making every PR painfully slow.

Scope

• Separate test lanes by speed and dependency profile.
• Decide which suites run on every PR, which run conditionally, and which run on merge/nightly.
• Document expected runtime and purpose for each lane.

Proposed lanes

Fast PR lane

• unit tests
• lint
• no-dependency in-process integration tests

Medium lane

• Redis-backed integration tests

Slower/deeper lane

• black-box container smoke tests
• Helm/deployment smoke tests
• optional burst/backpressure scenarios

Deliverables

• CI workflow updates or a concrete workflow design proposal.
• Documentation of when each suite runs.
• Guidance for local execution.

Acceptance criteria

• CI has a clear layered strategy instead of a single test bucket.
• Contributors can tell which suite failed and why.
• Test confidence improves without overloading normal PR iteration.