bug(claude): a short prompt already contained in the composer's dim suggestion never confirms #1230

What happens

Delivery confirms a short prompt by finding its tail (the last 24 normalised characters) in activeClaudeComposerText. When the baseline composer ALREADY contains that tail, tailAlreadyPresent disables the inline signal. A short raw write never produces a [Pasted text #N] placeholder, so the delivery can never confirm. It waits the full 5 s, rolls back, and fails.

Two shapes reach this:

• A prompt contained in Claude's dim placeholder suggestion. The suggestion renders in the empty composer, and activeClaudeComposerText reads it as text. Example: baseline ❯ Try "git status" or "/help" to get started with prompt git status.
• A prompt that is exactly the marker ❯. The idle composer segment is ❯. This is only reachable from remote or mobile input.

Measured in the #1226 review (reviewer A, scratch simulator on the recorded 2.1.278 frame):

new | 'git status' + image | ok=False code=absorption-timeout enter=False
old | 'git status' + image | ok=True  enter=True

The text-only path has made the same trade for every short prompt since #1219. #1226 extends it to image sends.

Evidence still needed (staged decomposition)

• A recorded frame with a dim suggestion in the composer, with cell attributes. The one hint so far is the user note in testing/fixtures/image-reads/claude-user-attachment.json: "prompt lns are shown with less opacity in the composer, fooling our system".
• Whether readiness (which is attribute-aware) and activeClaudeComposerText (which is not) disagree on that frame.

Likely fix direction

Take the composer text with dim cells excluded, the way readiness already classifies the empty composer. The alternative is to accept "composer text changed from baseline AND contains the tail" when the tail was already present. Decide from the recording.

Refs #1219, #1226.