Compose intent: hard enforce in-reply / nested-only mode for automation clients

[Trace824]

Summary

Automation that intends only in-thread replies can still open root compose (SideNav_NewTweet_Button / compose/post) and publish a root tweet by mistake. Clients need a hard enforce option for nested/in-reply-only sends.

Repro

• Context: Agent/tooling meant to reply in-thread only.
• Steps:
  1. Navigate to a thread; optionally open root composer instead of reply composer.
  2. Fill draft and click post.
• Observed: accidental root tweet possible when compose intent is wrong; standing product expectation for many bots is nested-only.

Code pointers (verified against /workspace/FSB)

• extension/site-guides/social/twitter.js — SideNav_NewTweet_Button, reply vs inline tweet buttons (~L48, ~L139–151).
• extension/catalog/handlers/mastodon.js — in_reply_to_id pattern (catalog precedent; X path may differ).
• Likely area: guard on send that URL/DOM indicates reply context (status reply composer) when a client flag requests nested-only — design carefully; do not invent an X API.

Proposed fix

Add an optional compose-intent guard: when enabled, refuse send unless the composer is clearly a reply (in-reply UI / URL), blocking root compose/post sends. Document selectors that distinguish reply vs root compose in twitter.js.

Acceptance / regression

• Nested-only mode blocks root compose send; allows in-thread reply send.
• Default behavior unchanged for general users.

Owner

extension

---

Priority: P2 · Owner: extension