fix: namespace the context keys and read the request container as a local

[lesnik512]

The plugin stored its two containers in FastStream's ContextRepo under generic names, so a user's own context entries could replace them.

Changes

• The keys are now modern_di_root_container and modern_di_request_container (previously di_container and request_container). Both are private constants; fetch_di_container remains the public way to reach the root container, so this is not a breaking change.
• FromDI resolution reads the request container with ContextRepo.get_local. ContextRepo.get checks globals before locals, so a global with the same key would win over the per-message container. get_local only sees the value the middleware set with context.scope.

Where the request container collision shows up

On FastStream 0.7.7 a broker attached to an app gets a ContextRepoComposition. The middleware's context.scope writes to the composition's inner repo, and get walks the repos in order. A global passed via FastStream(context=ContextRepo({...})) lives in a later repo, so it does not shadow the request container. A global set through broker.context.set_global(...) (or the context injected into a handler or hook) lands in the inner repo next to the local and does shadow it. The new test uses that path. get_local alone fixes this case; the rename covers it as well.

Tests

• test_from_di_ignores_a_user_global_named_request_container: sets a request_container global on the broker's context and checks that FromDI still resolves from the request container.
• test_fetch_di_container_ignores_a_user_global_named_di_container: sets a di_container global after setup_di and checks that fetch_di_container still returns the container passed to setup_di.

Both failed on main before the fix. Existing tests pass unchanged; one docstring now names get_local in place of get.

Closes #74
Closes #75