Choose typed discovery warnings or `st2 validate --json` as the consumer boundary

[schickling-assistant]

Current state

PR #93 made an explicit Agent Spec identity plus host authoritative independent of declaration path. Fully explicit placement therefore produces no path-mismatch warning and must remain path-independent.

When either field is omitted, path-derived defaults still participate in placement and mismatches remain advisory. Current discovery warning strings prefix the declaration path, but agent_spec::Discovered.warnings is still Vec<String>, so a direct crate consumer must parse human prose to recover a stable warning kind or structured path.

The maintained st2 validation surface already exposes structured issues through st2 validate --json:

• stable code;
• declaration path;
• resolved agent when known;
• severity; and
• human message.

Decision required

Choose and document one supported library-consumer boundary:

1. Introduce a typed Agent Spec warning such as SpecWarning { path, kind, message }, accepting and managing the breaking change to Discovered; or
2. Keep discovery warnings as human diagnostics and designate st2 validation's structured issue report / validate --json as the supported attribution surface for consumers.

The goal is not to duplicate warning ontologies. A consumer should have one supported way to attribute each remaining warning to a declaration and distinguish its kind without matching prose.

Acceptance boundary

• Explicit identity plus host remains path-independent and warning-free for folder mismatch.
• Partial declarations retain path-default mismatch diagnostics.
• Every warning exposed through the chosen consumer API has a stable kind and structured path.
• Tests distinguish fully explicit placement from partial placement.
• Existing parse errors remain path-attributed.

Non-goals

• restoring canonical-path authority;
• warning on ordinary organizational or dot-prefixed declaration placement;
• changing identity/host precedence;
• creating two competing structured warning models; or
• treating advisory placement warnings as launch failures.

This remains a low-priority API-shape backlog item, not active WORK or SITREP, until a direct library consumer requires a choice.