fix(hub): implement implicit recipient fallback for agent outbound messages

[iJuanPablo]

Fixes #1229

Summary

handleAgentOutboundMessage's doc comment and an inline comment both
promise that outbound messages default their recipient to the agent's
creator when none is explicitly specified, but that fallback was never
implemented — the function returned a 400 "recipient is required"
immediately whenever both recipient and recipient_id were empty.

This silently broke every automatic reply-forwarding path, most notably the
assistant-reply Stop hook (pkg/sciontool/hooks/handlers/hub.go) used by
both the web dashboard's Messages tab and the Telegram plugin: an agent's
final reply is captured by the hook and forwarded via
SendOutboundMessage(), which never sets Recipient/RecipientID, so the
Hub rejects it with 400 and the reply never reaches the user.

Fix

When no recipient is given at all, resolve agent.CreatedBy (falling back
to agent.OwnerID for agents created by automation with no creator) via
store.GetUser, mirroring the existing explicit-recipient resolution logic
just above it (email lookup / display-name search / "user:<name>"
formatting).

Testing

• Added TestOutboundMessage_ImplicitRecipientDefaultsToCreator — creates
  an agent with CreatedBy set and no recipient in the request, asserts a
  2xx response instead of the previous 400.
• go build ./pkg/hub/... — clean.
• go test ./pkg/hub/... -run TestOutboundMessage — all pass, including the
  new test and the existing TestOutboundMessage_UnknownRecipient (explicit
  bad recipient still correctly rejected).
• Full go test ./pkg/hub/... — same 5 pre-existing failures on unpatched
  main (TestClassifyPath_ManagedPath, TestClassifyPath_ManagedLegacyGroves,
  TestFSValidatePath_ManagedOverlap, TestFSList_HomeDir,
  TestFSList_DefaultsToHome — unrelated fs_safety/filesystem tests,
  verified to fail identically with this change stashed out).

[gemini-code-assist]

Code Review

This pull request introduces fallback logic in handleAgentOutboundMessage to automatically resolve the recipient to the agent's creator (or owner) when no recipient is specified, accompanied by a new unit test to verify this behavior. The review feedback correctly points out that silently ignoring errors from s.store.GetUser can mask transient database issues as validation errors (400 Bad Request) instead of returning an internal server error (500), and suggests properly handling these errors.

[gemini-code-assist]

Silently ignoring all errors from s.store.GetUser can lead to misleading behavior. If a transient database error occurs (e.g., connection timeout), the function will silently fail to resolve the recipient and proceed to return a 400 Bad Request ("recipient is required") instead of a 500 Internal Server Error.

We should check if the error is a real database error (not store.ErrNotFound) and return a proper server error to the client.

			u, err := s.store.GetUser(ctx, creatorID)
			if err != nil {
				if !errors.Is(err, store.ErrNotFound) {
					writeErrorFromErr(w, err, "Failed to resolve agent creator")
					return
				}
			} else {
				recipientID = u.ID
				name := u.DisplayName
				if name == "" {
					name = u.Email
				}
				recipient = "user:" + name
			}

[ptone]

Thanks so much for your contribution - there are a couple reasons this may not be best way forward.

1. explicit better than implicit - while the docs/contract may indicate the implicit fallback as a plan - I think sending errors early on in agent sessions builds better "habits" and results in more consistent tool use -- I've seen agents develop "lazy/sloppy" habits in using messaging if they don't get errors on mis-use early on (there are places where this needs tightening.

2. the other reason - is now with chat, and the native chat becoming more prominent, I want a channel+thread to be a valid "recipient" and get across the idea that you are posting to a chat space, not to a person.

If there is a specific creator recipient - this makes a channel target a little more ambiguous - WDYT?

which chat integration are you using the most?

[stevegeek]

I've been trying to work through this issue too, and understand the desire for it not to be implicit. I worked with Claude to try to solve this differently and have a possible proposal in #1259: rather than defaulting the recipient, it records the thread alongside the channel in the existing reply-affinity context, so an agent's untagged reply lands back in the conversation it answers, ie addressing the where rather than the who.

[ptone]

See the proposed plan at #1264