Expose Sharingan.configure(capacity) for store capacity (HITL — public API decision)

[mibrahimdev]

What to build

HITL — public-API decision. The shared Sharingan facade hardwires SharinganStore() at the default capacity (300). Today only a hand-built store passed to every entry point can change capacity, which is an inconsistent split (MQTT/BLE via the facade always hit 300).

Decide and expose a clean one-time configuration path — e.g. Sharingan.configure(capacity = …) — or deliberately document the "build your own store and pass it everywhere" path as the supported approach. Because this adds public API surface, the shape needs maintainer sign-off.

Acceptance criteria

• Decision recorded: configure(capacity) entry point vs. documented build-your-own-store path
• If adding API: one-time configuration applies consistently to facade, MQTT, and BLE entry points
• Mirrored in :sharingan-noop to preserve API parity
• BCV .api dumps updated; docs/sample updated

Blocked by

• None - can start immediately

[mibrahimdev]

Closing in favour of the persistence design session (#27). The maintainer's call (2026-06-14): a standalone in-memory configure(capacity) would be throwaway surface because once we persist logs to a local DB (the flight-recorder path), "capacity" becomes a retention policy (max sessions / age / rows). So the configuration knob is folded into #27 and added additively then, rather than shipping an in-memory-only version now. Rationale recorded in docs/ROADMAP.md (PR #28).