A documented procedure to withdraw a bad release #321

Part of #93 (release gates; from the #311 review, Group E). Owner: not assigned. Task base and PR target: develop. Independent; the optional design part depends on #157 and #213.

Intended behavior

When a published release is bad, the operator follows one written procedure that moves every Home to a good release, and the Homes that have not yet updated stop being offered the bad one.

Current behavior

• Homes refuse a lower version unless the user runs an explicit Undo (elastos/crates/elastos-server/src/update.rs, the version-order check before install). The seed keeps every release pinned.
• docs/VERSIONING.md describes how to publish, but not what to do when a published release is bad. The only path is publishing a newer release, and nothing documents it.

Done means

• docs/VERSIONING.md has a "Withdraw a bad release" section. It covers publishing N+2 built from the last good source, the communication on 0.8.0: Release 0.8.0 #93, the Undo instructions for affected users, and what the seed keeps. The section is at https://github.com/Elacity/elastos-runtime/blob/aa3d61e4478a1a1a63dbef0dae97c23a0f9f4851/docs/VERSIONING.md#L332. Test: Anders reads it and approves.
• Moved to 0.8.1: 0.8.1: Decide whether the signed head lists withdrawn versions #367 (decision on a withdrawn-versions list in the signed head, with Design signed release-head freshness and explicit gateway freeze reporting #157 and Publisher key rotation without reinstalling: a root key delegates release signing keys #213).