[lesnik512]

@inject, and DITask, which uses it, looked the container up through current_app at call time. When one process held several apps, a task registered on app b resolved from app a's container whenever a was current, with no error. That happened in eager mode and on a direct task() call. A normal celery -A b worker makes b current, so worker runs were not affected. Tests with more than one app, or code calling another app's task, were.

The wrapper now takes the app from the running task (current_task). Celery pushes the task onto its stack in the worker, in eager apply and on a direct task() call. When the decorated function runs outside any task, the wrapper falls back to current_app as before. This brings per-task lookup in line with the worker signals, which since #44 act only for the app that owns the container.

Tests:

• test_a_task_resolves_from_its_own_app_when_another_app_is_current covers @inject and DITask, through both .delay() and a direct call. It fails on main with 'other' == 'owner'.
• test_inject_outside_a_task_resolves_from_the_current_app covers the fallback.

The modern-di Celery docs page says the lookup goes through current_app; a follow-up PR there updates that sentence.