refactor(edit): decide whether an edit is sent in one place

[ryanlewis]

runEdit decided "will this edit be sent" twice, in two hand-written conditions: once before the tag check (to check the auth token before --create-tags makes a tag) and once at the no-op early return for an already-closed item. Both now go through sendsEdit(already, reveal, changed), whose doc comment states the one rule: only an item already in the closed status asked for, with no --reveal and nothing else to change, goes unsent.

Before the tag check, the only change known is a tag --create-tags will make, so that check asks sendsEdit(already, reveal, false) || createsTags(...). The tag lookup still runs only when the edit would otherwise go unsent, as before. After the no-op check, changed is the whole answer.

Behaviour is unchanged.

Tests

• TestEditAlreadyClosedWithChangeNeedsAuthToken: an already-closed item with --title or --reveal and no auth token is refused with update: auth token is required, and nothing runs. It passes on main and on this branch.
• TestSendsEdit covers the rule's four cases.
• The existing tests TestEditAlreadyClosedNeedsNoAuthToken, TestEditAlreadyClosedExistingCreateTagsNeedsNoAuthToken and TestEditMissingTokenRefusedBeforeTagsCreated cover both checks and still pass.

/code-review

• Applied: put back the short-circuit, so the tag lookup does not run for an edit already known to be sent; run the new test's cases under t.Run; fix the test comment.
• Not applied, because it changes behaviour: for an already-closed item with a real change and no token, edit prints note: "X" is already completed; the status is left out of the edit and then fails with auth token is required. A token check before the note would fix that. I left it as a follow-up.