Proposal: expose post-spawn runtime provenance for Desktop-managed agents

## Problem

Desktop can show the binary path discovered while configuring a harness, and it
stores PID/runtime ownership receipts. Neither proves which executable a
managed agent actually ran after spawn.

That gap matters when:

- an installed release can see a build checkout and resolves a stale first-party
sidecar (the class tracked in #2655);
- packaging or caches select an artifact from a different run (#5429);
- a signed/notarized workflow reports success but a published artifact later
fails local verification (#3933); or
- a configured model differs from the adapter/provider's effective model
(#4004).

The user-visible failure can be “everything looks healthy, but the agent is
running different code or a different model.” A pre-spawn discovery path and a
package version are not sufficient evidence.

## Question for maintainers

Would Buzz accept a portable, structured runtime-provenance surface for
Desktop-managed agents? Before implementation, the contract should choose:

1. **Consumer:** Doctor/Harness Catalog, Activity, a local diagnostics export,
or an observer event.
2. **Identity strength:** release/build id only, canonical executable path,
SHA-256, platform signature identity, or some combination.
3. **Privacy:** whether full local paths leave the host; a redacted basename +
digest may be safer for relay-visible events.
4. **Timing:** discovery, immediately after spawn using the child PID, first ACP
initialize/session response, or first completed turn.
5. **Model semantics:** keep requested, adapter-accepted, and provider-reported
model separate; missing provider model must remain “unavailable,” not
“matched.”

## Suggested smallest slice

Add a local structured diagnostic for one managed runtime instance containing:

- Desktop package version and immutable build/release identity when available;
- actual running Desktop executable identity;
- actual child broker executable identity derived from the spawned PID;
- parent/child runtime receipt linkage;
- configured/requested model;
- adapter-accepted model when the ACP response makes it provable; and
- provider-reported effective model when usage supplies it.

The diagnostic should distinguish `unavailable`, `not_applicable`, and
`mismatch`, and should never include credential values. Hashing should be
cached per immutable file identity so a status poll does not reread large
binaries continuously.

## Non-goals for the first slice

- changing first-party sidecar resolution (#2655);
- changing macOS signing/TCC behavior (#2783/#2785);
- replacing platform signature or Gatekeeper verification;
- publishing local filesystem paths to a relay by default; or
- making optional provider model reporting mandatory for every adapter.

This should be an issue-level contract first because the same data can be a
useful local diagnostic, a privacy leak, or an incorrectly promoted attestation
depending on where it is emitted and consumed.