Fix the tombstone flow, and watch what Cyd actually sends

[micahflee]

Closes #712.

Work from the manual verification in #712. The X automation was already
repaired; everything here was found by running it by hand against a seeded
test account, which is what that ticket exists to do.

Tombstone

Five bugs, none in the automation, all in what surrounds it.

• The finished page rendered its heading above nothing. It has a block per
  jobs type and none matched tombstone, so the one run whose purpose is
  changing how your profile looks to other people never said what it changed.
• The bio field offered the bio the tombstone had just replaced. Cyd's
  saved copy is written at login and nowhere else. The job now writes back the
  value it reads off X to confirm the save, on the success path only.
• Waiting for a crop step X does not always show turned a run that was
  about to succeed into a timeout.
• The banner read-back asked before the page had drawn anything, got ""
  from both reads, and called a save that worked unchanged.
• The banner read-back asked once, in a 200ms gap. The profile draws the
  banner it already had and replaces it a moment later, so a successful save
  read as no change. It is read now until it differs.

Watching the requests

CYD_REQUEST_LOG=/tmp/dir npm start records the method, URL and status of
what Cyd's own session sends. Off unless asked for. No bodies, headers or
cookies, and never attached to an error report — the reasoning ADR 0005
applies to archives applies here too.

It was built because the capture tooling drives a separate Chromium, so its
findings describe Chromium. That is fine until the app and the probe disagree,
which is where this stood: a banner that uploaded under Playwright and did not
under Electron, with nothing recorded on the Electron side to compare.

It answered that in minutes, and the answer was not what any of the DOM
theories predicted:

20:00:18.471  POST 201  i/media/upload.json?command=FINALIZE
20:00:25.671  POST 200  account/update_profile.json
                        update_profile_banner.json   ← never called

The image uploads; the call attaching it never happens. Apply is not a step X
sometimes puts in the way — it is what stages the upload as the banner. So a
delivery drawing no crop is made again, up to three times, and if X never
offers one that is the error, said plainly.

This also removes a test that asserted saving without a crop succeeds. It
passed, and it was wrong: nothing had watched what X was really sent.

Seeding

Found while re-seeding the test account.

• The composer close check never matched. /compose/post is a modal over
  the home timeline, whose own composer carries the same test id, so the wait
  retargeted to it the moment the modal closed. Every successful post was
  reported as a failure and retried — a 41-post seed would have triple-posted.
• Likes and bookmarks reached for a climbing index against a virtualised
  timeline where acted-on posts leave the selector. 4 failures in 41 likes
  before, 0 after acting on the first post still offering the action.
• The scroll gave up short once enough posts were done, on an image-heavy
  feed.
• Long-form is gone. It needed a premium account, so it was always skipped
  and never seeded. Accepted knowingly: no seeded post, no fixture, no marker.

Verification

Seeded @nexamind91326 and verified against the account, not the progress log:
41 posts, 41 likes, 41 bookmarks, 25 following, plus a self-thread, one-image,
four-image and video posts, a poll, a link card, 2 quotes and 2 retweets.

The delete run, read back out of the request log: DeleteTweet 51,
DeleteRetweet 2, UnfavoriteTweet 42, DeleteBookmark 42,
friendships/destroy 25 — every call 200, no rate limits, and the account
left empty on every timeline. Zero direct-message API calls across 3,444
requests, which confirms against real traffic what view_model.test.ts
asserts.

The tombstone has since run three times in a row without failing, across two
accounts.

Suite: 119 files, 1499 tests, no type errors.

What merging this accepts

This closes #712, so it is worth being explicit about what the ticket's
remaining criteria rest on.

The delete run is verified above, against the request log and the resulting
account state. The tombstone has run three times without failing. The full
suite is green.

The save run, the un-loadable-timeline error report and the empty-account run
were exercised by hand rather than recorded here. The direct-message archive
criterion was struck from the ticket by decision, not by test: the data half
stays covered by archiveBuild keeps saved conversations and messages in the archive, and the archive site's messages view remains untested by anything,
which is a known and accepted gap.

🤖 Generated with Claude Code