Release checklist updates in the wake of 0.80.

'Merge the release branch to main' shouldn't be half way down the
procedure of actually _doing_ the release. Sometimes it's not trivial!
This time, for example, major changes in windows/console.c had taken
place on main (the ConsoleIO abstraction) which conflicted with also-
major changes on the release branch (the rework of the weak-crypto
warning messages to use SeatDialogText, for the Terrapin warning).
Suddenly I realise it makes more sense to prepare the merge in
advance, and then if it's difficult you get time to think about that
and solve it at leisure.

Also, I'm on Mastodon these days, and that seems like an obviously
useful place to announce releases. Added a checklist item to draft a
release toot, and another one to send it.

Lastly, I managed to miss my own suggested template wording for MS
Store 'what's new' text, even though it was right there in the
checklist! Expanded it out into a display paragraph or two, so that
it's more obvious.

CHECKLST.txt

@@ -164,13 +164,24 @@ Preparing to make the release
 
  - Prepare some 'what's new in this release' blurb for the Windows
    Store. This should be very brief - even briefer than the website
-   news item. Keep it to a couple of sentences in a single paragraph,
-   templated along the lines of 'X.YZ adds support for this, that and
-   the other, and fixes bugs including this and that', or 'X.YZ is a
-   bug-fix release, mostly in the area of Foo, with one important fix
-   to Bar'.
+   news item.
+    * Keep it to a couple of sentences in a single paragraph,
+      templated along the lines of
+        X.YZ adds support for this, that and the other, and fixes bugs
+        including this and that.
+      or
+        X.YZ is a bug-fix release, mostly in the area of Foo, with one
+        important fix to Bar.
     * Might as well check this into putty-aux too.
 
+ - Prepare a toot! I'm on Mastodon, so I should announce the release
+   there. This means writing a cut-down 500-char announcement, maybe
+   more like the website news item than like the email.
+    * Include any relevant hashtags. Refer to the software as #PuTTY;
+      if you mention SSH then write it as #SSH; similarly if we're
+      fixing a #vulnerability. That's how people will find the toot.
+    * Again, commit to putty-aux for team review.
+
  - Update the wishlist, in a local checkout:
     * If there are any last-minute wishlist entries (e.g. security
       vulnerabilities fixed in the new release), write entries for
@@ -196,6 +207,14 @@ Preparing to make the release
      sh sign.sh -r putty     # and enter the release key passphrase
      chmod -R a-w putty
 
+ - If the release is on a branch (which I expect it generally will
+   be), prepare a merge of that branch to main. Even if the branch
+   consists of nothing but cherry-picks _from_ main, this will mean
+   that the 'update version number' change appears on main and the
+   snapshots start announcing themselves as post-X.YZ. But also, if
+   there's anything new on the branch, this is how it gets on to main
+   as well.
+
 The actual release procedure
 ----------------------------
 
@@ -219,18 +238,12 @@ locally, this is the procedure for putting it up on the web.
    correctly and work:
       ../putty/release.pl --version=X.YZ --postcheck
 
- - If the release is on a branch (which I expect it generally will
-   be), merge that branch to main, so that the 'update version number'
-   change appears on main and the snapshots start announcing
-   themselves as post-X.YZ.
-
  - Push all the git repositories:
     * run 'git push' in the website checkout
     * run 'git push' in the wishlist checkout
     * push from the main PuTTY checkout. Typically this one will be
-      pushing both the release tag and the merge we just made to the
-      main branch, plus removing the pre-release branch, so you'll
-      want some
+      pushing both the release tag and the merge to the main branch,
+      plus removing the pre-release branch, so you'll want some
       commands along these lines:
         git push origin main          # update the main branch
         git push origin --tags        # should push the new release tag
@@ -276,6 +289,7 @@ locally, this is the procedure for putting it up on the web.
     + Mail that release announcement to
       <putty-announce@lists.tartarus.org>.
     + Post it to comp.security.ssh.
+    + Post the prepared toot to Mastodon.
     + Mention it in <TDHTT> on mono.
 
  - Edit the master ~/adm/puttysnap.sh to disable pre-release builds,