core: use case doctrine test

[absoludity]

Follows #108. CI passes here because it doesn't yet run the doctrine tests - I'll follow-up with a PR that adds them and fixes the failures in the current code for use-cases, before adding the other doctrine tests. Running manually, it fails with:

FAILED src/julee/core/doctrine/test_use_case.py::TestUseCaseStructure::test_all_use_cases_MUST_have_matching_request - AssertionError: Use cases missing matching requests:
FAILED src/julee/core/doctrine/test_use_case.py::TestUseCaseStructure::test_all_use_cases_MUST_have_matching_response - AssertionError: Use cases missing matching responses:
FAILED src/julee/core/doctrine/test_use_case.py::TestUseCaseStructure::test_all_use_cases_MUST_have_execute_method - AssertionError: Use cases missing execute() method:

which answers a question I had about the seemingly superfluous request/response classes (created to ensure the name matches the use case).

ADR 002 establishes that doctrine tests are the authoritative expression of
architectural rules — the docstring states the rule, the assertion enforces
it. This PR delivers the first of those tests, covering use cases.

The test scans the entire codebase at runtime and verifies that every class
ending in `UseCase` has a docstring, an `execute()` method, and matching
`Request`/`Response` classes in the same bounded context. Running
`pytest src/julee/core/doctrine/` against any Julee solution will surface
violations immediately.

The 3 failing tests on this branch are real violations in existing code, not
test bugs. They are the point — this is the doctrine working as intended.
Fixing those violations is follow-on work, separate from landing the
enforcement mechanism.

The `JULEE_TARGET` env var lets the same test suite run against any
external Julee solution, not just the framework itself.

Part of a stack

1. Domain models and constants
2. Griffe-based bounded context scanner
3. Introspection use cases
4. This PR — use case doctrine test

[absoludity]

I don't understand the "shared domain" - shared as in it's used by other applications? That terminology seems to have been used (along with a "shared directory" where the tests would go, but they're all in src/julee/core as if that assumption changed?

[absoludity]

Note the difference between these imports ... one from file the other not. That's what I referred to in a previous PR.

[absoludity]

Why not have the return type as the protocol here - does it need to be implementation specific ^^