feat: context-manager form of Container.override via OverrideHandle (INT-4)

[lesnik512]

The accepted INT-4 item from the 2026-07-05 3.0 UX research: container.override(provider, obj) keeps applying the override immediately and now returns a generic OverrideHandle; used as a context manager, __exit__ restores the provider's prior override state — the previously stacked override if there was one, otherwise no override. __enter__ returns the override object, so with container.override(p, mock) as m: binds the mock.

• Snapshot semantics: the handle captures the prior state at the override() call and restores it unconditionally on exit — deterministic under nesting (per-handle snapshots; the registry stays a flat dict), on exception, and even if reset_override()/root close_*() ran inside the block. Handles unwind LIFO (with-blocks do this naturally); the docs note manual out-of-order exits can restore stale state.
• Non-breaking: imperative callers ignoring the handle see identical behavior (verified: no in-repo caller asserts on the old None return). reset_override untouched; no new exceptions or warnings; zero new lint suppressions.
• Docs: recipes/testing-overrides.md leads with the with form as the primary testing spelling; for-fastapi-users.md maps it to the dependency_overrides try/finally pattern; the dependency-injector migration mapping is de-drifted; architecture/testing-and-overrides.md promoted.
• Gates: just test-ci (100% line coverage, 325 passed), just lint-ci, just docs-build --strict, just check-planning — all green. Adversarial final review probed cached-factory short-circuit order, falsy overrides, child-container handles after close, cross-provider nesting, and close-inside-block — all consistent with the documented semantics.

Design bundle (rationale home): planning/changes/2026-07-08.03-override-context-manager.md

🤖 Generated with Claude Code