refactor(threads): inject adapter runtime dependencies

[shuxueshuxue]

Summary

• inject runtime thread activity, chat runtime services, and thread input handler dependencies instead of letting adapters hold the whole app and reach into state at runtime
• keep the slice focused on the chat/threads seam only, with matching fixture updates for the new constructor contracts

Proof

• uv run pytest -q tests/Unit/backend/test_thread_activity_reader.py tests/Unit/backend/test_chat_runtime_services.py tests/Unit/backend/test_thread_input_handler.py -> 5 passed
• uv run pytest -q tests/Unit/backend/web/services/test_agent_runtime_gateway_thread_input.py tests/Unit/backend/web/services/test_agent_runtime_gateway_chat_delivery.py tests/Integration/test_messaging_social_handle_contract.py -k "agent_runtime_gateway or latest_live_child_thread_over_active_main or recipient_thread_resolution_requires_current_thread_repo_contract or uses_recipient_social_user_id_for_thread_lookup_and_passes_through_envelope_content" -> 11 passed, 102 deselected
• targeted ruff check / ruff format --check / git diff --check green

Commit Density

• this PR keeps 6 commits to satisfy the repo rule of at least 5 commits per PR

[shuxueshuxue]

Focused review on the adapter-injection slice: no blocking findings from my side.

I checked the constructor-contract changes across the activity reader, chat runtime services, thread input handler, bootstrap wiring, and the updated fixture surface. The write set stays inside the chat/threads adapter seam, and the touched tests now exercise the explicit injected dependencies rather than the old implicit app-state reach-through.

I am separately parking a /api/monitor/threads hang investigation because that read path overlaps this seam. Once this lands on shared dev, I will rerun that branch-local probe on the fresh head instead of competing on the same files now.