fix: mobile composer, agent draft allowlist, git push DX, duplicate-session warning

[Chessing234]

Summary

Stacked fixes across mobile, CLI/desktop agent drafts, relay auth, and git DX — 11 commits in one PR:

1. Mobile channel composer: make Enter insert a newline instead of sending #3725 — mobile channel composer: Enter inserts a newline; send stays on the button
2. feat(cli): owner-reviewed agent drafts cannot grant "Selected people" access — respond-to is limited to owner-only / anyone #3792 — CLI draft-update supports --respond-to allowlist + --respond-to-allowlist
3. feat(cli): owner-reviewed agent drafts cannot grant "Selected people" access — respond-to is limited to owner-only / anyone #3792 — Desktop round-trips allowlist (stop clearing Selected people on draft apply)
4. Same agent key running in two places — both reply, nothing detects it #3832 — Relay NOTICE + warn log when a second session auths as the same pubkey
5. Same agent key running in two places — both reply, nothing detects it #3832 — ACP README: remote-only agents / duplicate-key hazard
6. Hosted relay git push limited to ~5 MiB packs (code default 500 MB); over-limit and chunked pushes fail opaquely #3802 — Clearer HTTP 413 for over-limit git packs + hydrate ResourceLimit detail
7. Hosted relay git push limited to ~5 MiB packs (code default 500 MB); over-limit and chunked pushes fail opaquely #3802 — .env.example + git-credential-nostr troubleshooting for postBuffer / pack limits
8. .env.example: BUZZ_WEB_DIR comment implies it alone serves the web frontend at /, but BUZZ_SERVE_GIT_WEB_GUI is also required #3815 — Startup log distinguishes invite-bundle-only vs full SPA (BUZZ_SERVE_GIT_WEB_GUI)
9. docs(presence): 90s TTL is documented as 3× a 30s heartbeat, but the agent harness heartbeats at 60s (real margin 1.5×) #3795 — Cross-ref 60s/180s presence invariant at the ACP heartbeat
   10–11. Follow-up tests/docs for the git 413 path

Skipped issues that already have open third-party PRs (#3816, #3857, #3865, #3849, #3885, #3856, #3847).

Test plan

• cargo test -p buzz-cli --lib agent_management
• node --test desktop/src/features/agents/agentManagement.test.mjs
• cargo test -p buzz-relay --lib git_body_limit_message_names_env_var
• Manual: mobile composer Enter → newline; send button still sends
• Manual: second buzz-acp with same key → NOTICE in logs
• Manual: over-limit git push → 413 naming BUZZ_GIT_MAX_PACK_BYTES

Closes #3725
Closes #3792
Closes #3832
Closes #3802
Closes #3795

Made with Cursor

[Chessing234]

Rebased with Signed-off-by so DCO Check is green.

[Chessing234]

Rebased onto latest upstream/main with Signed-off-by on all commits and force-pushed. CI should re-run shortly — still ready for @block/buzz-oss-team review when you have bandwidth.

[Chessing234]

@tlongwell-block @wesbillman @wpfleger96 mind taking a look when you get a chance?

[Chessing234]

multi-issue batch — if review is blocked on scope, i can split mobile composer / draft allowlist / git push dx into separate tips.

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is 78618804ec86a014524ad7d1fb55928e8f5c3edf...5d9b2811fe0204501a4ac3b0bf0c07b9f85ca14f.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review 5d9b2811fe0204501a4ac3b0bf0c07b9f85ca14f to authorize a new review.
Any previous review applies only to its recorded range.

[nathansmithopenclaw-alt]

Thanks for carrying the selected-people round trip for #3792. We have overlapping
fork work on this seam and do not plan to open a competing allowlist PR.

The interoperability checks that mattered in our implementation were:

• respondTo: "allowlist" requires at least one canonical pubkey;
• allowlist identities are normalized and deduplicated before the draft is
  published;
• unknown request keys are rejected rather than silently discarded;
• switching to owner-only or anyone does not retain a stale allowlist; and
• the owner review dialog displays the proposed people and remains editable
  before save.

The remaining design question is create/update parity. draft-create still
cannot propose selected people, while this PR correctly focuses on update. I
suggest keeping that expansion in a separate field-boundary issue so #3912 can
land without absorbing broader create configuration work.

We can help test the strict parser and review-dialog round trip once the PR is
ready; no need to duplicate the implementation.

[Chessing234]

rebased onto main