feat: group-level default scope via class RequestGroup(Group, scope=...) (API-4)

[lesnik512]

The accepted API-4 item from the 2026-07-05 3.0 UX research: a Group subclass may declare class RequestGroup(Group, scope=Scope.REQUEST); every Factory/ContextProvider declared in that class body without an explicit scope= takes the group's scope instead of Scope.APP. Non-breaking: groups without the kwarg and providers omitting scope behave exactly as before.

• Priority (dishka-style): explicit provider scope= > group scope= kwarg (nearest in MRO; a subclass's kwarg applies to its own body) > Scope.APP.
• Alias never participates — its scope derives from its source.
• A scope-defaulted provider shared by two groups with different defaults raises new GroupScopeConflictError at class creation (maintainer-ruled: import order must never decide a provider's scope); same default is a no-op. Ships with its troubleshooting page, catalog entry, and census bump (21→22 concrete exceptions).
• Mechanism: Group.__init_subclass__ + a defaulted-scope marker; the UNSET sentinel is normalized to Scope.APP inside AbstractProvider.__init__ and never leaks. No metaclass.
• Docs: canonical section in providers/scopes.md, cross-links, invalid-scope-type-error page covers its second raise site; architecture/providers.md promoted.
• Gates: just test-ci (100% line coverage, 320 passed), just lint-ci, just docs-build --strict, just check-planning — all green. Adversarial final review probed import-order flips, APP-stamp vs normalization ambiguity, subclass chains, multiple inheritance, and custom IntEnum scopes — all behave as specified.

Design bundle (rationale home): planning/changes/2026-07-08.02-group-default-scope.md

🤖 Generated with Claude Code