FEAT: Runtime capability discovery for prompt targets

[hannahwestra25]

Description

Adds query_target_capabilities.py, which probes a PromptTarget at runtime to determine what the underlying endpoint actually accepts. Useful for custom OpenAI-compatible endpoints, gateways that strip features, or any deployment where declared capabilities may not match real behavior.

New public API (exported from pyrit.prompt_target)

• discover_target_capabilities_async — probes boolean capability flags (SYSTEM_PROMPT, MULTI_MESSAGE_PIECES, MULTI_TURN, JSON_OUTPUT, JSON_SCHEMA).
• discover_target_modalities_async — probes which input-modality combinations are accepted.
• discover_target_async — runs both and returns a populated TargetCapabilities.

Each probe is bounded by per_probe_timeout_s (default 30s) and retried once on transient errors. The target's configuration is temporarily replaced with a permissive one so _validate_request doesn't short-circuit. Probe-written memory rows are tagged with prompt_metadata["capability_probe"] == "1".

Caveats (in docstrings)

• "Supported" means the request was accepted — silent ignores aren't detected.
• Output modality probing is intentionally not provided.
• Not safe to call concurrently against the same target instance.

Tests & docs

• 32 unit tests, 98% coverage of the new module.
• Notebook: 6_1_target_capabilities.ipynb.
• New subsection in 0_prompt_targets.md.

Also fix a test_common_net_utility.py which was mocking get_httpx_client with a bare MagicMock, which did not match the real async context-manager flow used by make_request_and_raise_if_error_async. That let the mocked response behave like raise_for_status was async, so production’s correct synchronous call triggered the coroutine was never awaited warning. The fix was to mock the async context manager explicitly, keep client.request as an AsyncMock, and return a real httpx.Response so raise_for_status stays synchronous like the real API.

[romanlutz]

but it could accept multiple pieces of different types, right? Like image + text

[jsong468]

Great work! see Roman's question about how this feature gets used

[rlundeen2]

This is a little confusing in terms of how they are grouped. Isn't modality a type of capability? For example, we have TargetCapabilities.input_modalities.

Should we just have one function, discover_target_capabilities_async? But potentially include modality capabilities. E.g. input_text could be a capability name.

[rlundeen2]

Actually, I understand the reason why modalities is separate. It makes sense because it may be tough to flatten.

However, I think there should just be one public method. discover_target_capabilities_async. It can be this method, and I think most people will just call it with the target.