Follow up PR #40 observability logging semantics and sensitive payload handling

[oscarvalenzuelab]

Context

While validating PR #40, I found two follow-up issues in the new observability logging added around blocked/resume flows.

Observed problems

1. dev.question.posted is emitted before delivery is confirmed.

   • In src/dev_sync/transports/socket_client.py, the event is logged before _send_and_wait() confirms the bridge accepted the request.
   • In src/dev_sync/bridge/server.py, the event is logged before TelegramHandler.ask() succeeds.
   • If the socket write fails or Telegram returns an error, the logs still claim the question was posted.

2. Raw blocked-session questions and operator answers are now written to structured logs.

   • This happens in src/dev_sync/transports/socket_client.py, src/dev_sync/transports/file_mock.py, and src/dev_sync/bridge/server.py.
   • src/dev_sync/core/obs.py introduces hash_text() with a docstring describing PII-sensitive payload handling, but the current events still include plaintext question and answer fields.
   • Because these records go to stdout and are captured by launchd, operator replies can end up persisted in plaintext log files.

Why this matters

• The event stream becomes misleading during delivery failures.
• The logs may retain sensitive human-entered content longer than intended.

Suggested fixes

• Split intent vs success events, or move dev.question.posted so it is only emitted after confirmed delivery.
• Remove plaintext question / answer fields from structured logs by default, or gate them behind an explicit debug setting and keep hashes/lengths as the normal path.
• Add regression tests for failed delivery paths so logging semantics stay correct.

Validation context

This was found while reviewing PR #40 locally and running the targeted test suite for the transport, bridge, docs, and new observability tests.