Add use-case docstring, execute and request/response doctrine tests

[absoludity]

Context

Use cases are the primary entry point for business logic in the Clean Architecture. The doctrine currently has no tests ensuring that use cases follow the expected structural conventions — that they are documented, that they expose a single `execute()` method, and that each use case is paired with matching `{Prefix}Request` and `{Prefix}Response` classes.

Without these tests, violations accumulate silently. Use cases can exist without docstrings, without an `execute()` method, or with request/response classes that are present in the module but never actually wired into the method signature.

Acceptance criteria

• Doctrine test: use case classes MUST have a docstring
• Doctrine test: use case classes MUST have an `execute()` method
• Doctrine test: use case classes MUST have a matching `{Prefix}Request` class in the same bounded context
• Doctrine test: use case classes MUST have a matching `{Prefix}Response` class in the same bounded context
• Doctrine test: `execute()` MUST declare its first parameter as `{Prefix}Request`
• Doctrine test: `execute()` MUST declare its return type as `{Prefix}Response`
• Tests use runtime inspection with AST fallback for bounded contexts whose classes cannot be resolved at import time

Related

• `src/julee/core/doctrine/test_use_case.py` (implement here)
• `src/julee/core/entities/code_info.py` (MethodInfo has `return_type` and `parameters` from AST)
• Issues Add entity immutability doctrine test #94, Add one-repository-per-entity doctrine test #99 (same pattern — documented principle, no enforcement)
• Tier 1 priority (core structural contract for every use case)

[absoludity]

This is done in PRs #106, #107, #108, #109 and #110