v0.5.0 - Handle OpenAI response.metadata stream events

Compared against v0.4.0 (934e54a).

Published crate bumps:

• halter 0.4.0 -> 0.5.0
• halter-config 0.4.0 -> 0.5.0
• halter-hooks 0.4.0 -> 0.5.0
• halter-protocol 0.4.0 -> 0.5.0
• halter-providers 0.4.0 -> 0.5.0
• halter-runtime 0.4.0 -> 0.5.0
• halter-session 0.4.0 -> 0.5.0
• halter-tools 0.4.0 -> 0.5.0

halter-cli also moves to 0.5.0 but remains publish = false. The vendored
halter-brush-core (0.5.0) and halter-brush-builtins (0.2.0) are unchanged
and were not republished.

Changes:

• The OpenAI Responses stream no longer fails a turn on an event type the
  async-openai schema does not model. response.metadata — emitted by the
  ChatGPT/Codex backend with moderation scores attached — aborted the turn
  with a deserialization error. Unrecognized response.* frames are now
  logged and skipped, so an unmodelled frame costs one event rather than the
  whole turn, including text already streamed.
• New StreamEvent::ProviderMetadata and SessionEventPayload::ProviderMetadata
  carry out-of-band provider annotations to the consumer event stream as
  verbatim JSON text. The runtime does not interpret them; they surface in
  halter-cli --streaming-json as "kind":"provider_metadata".

Upgrading from 0.4:

• This is a minor release because both enums above are public and not
  #[non_exhaustive]. Exhaustive matches over either need a
  ProviderMetadata { metadata } arm; consumers with nothing to do with
  provider annotations can let it fall through an existing catch-all.

Known gap: the sibling safety_buffering field on Responses frames is still
dropped — see #191.

See CHANGELOG.md for full detail.