docs: Consistently say "18 months" on compatibility, no specific version numbers.

Previously I've wanted to have this page spell out the concrete
version number that our clients support, rather than the policy we
use for determining that version number, because that's the sort of
question that I feel like as a user I'd want a straight answer to
and would be annoyed if I couldn't get one.

But as the text stands, it's come to look more like it's the policy
(something that's heavyweight to change) than like the value that
the policy currently happens to work out to.  Also, because this page
is kind of chaotically organized (and fixing that is a bigger yak
than I want to shave right now), it repeats the 18-month rule in
three separate places and the current value (version 4.0) is in
a fourth separate place, so it looks internally inconsistent.

Let's therefore take a different tack: like in those other three
spots on this page, state just the policy instead of the value it
currently works out to; but also add a link to help the reader
pin down for themselves what value that does work out to.

This also means we no longer need to update this page as old releases
age and that value advances.

Also fix a typo, and cut the reference to working degraded on
older releases.  Starting earlier this year we finally started
hard-refusing such connections:
  https://github.com/zulip/zulip-mobile/issues/5102
  https://github.com/zulip/zulip-mobile/pull/5633
(which was because there were some swathes of compatibility code
that we could only cut if we completely broke the handling of
ancient servers, and so we preferred to have the app communicate
that break clearly up front.)

docs/overview/release-lifecycle.md

@@ -43,6 +43,8 @@ server repository][zulip-server].
   upgrading to a new major release series, We recommend always
   upgrading to the latest maintenance release in that series, so that
   you use the latest version of the upgrade code.
+- For the dates of past stable releases,
+  [see the Zulip blog][blog-releases].
 
 Starting with Zulip 4.0, the Zulip web app displays the current server
 version in the gear menu. With older releases, the server version is
@@ -55,6 +57,9 @@ documentation](https://zulip.com/api/), and [Integrations
 documentation](https://zulip.com/integrations/), are distributed with
 the Zulip server itself (E.g. `https://zulip.example.com/help/`).
 
+[blog-major-releases]: https://blog.zulip.com/tag/major-releases/
+[blog-releases]: https://blog.zulip.com/tag/release-announcements/
+
 ### Git versions
 
 Many Zulip servers run versions from Git that have not been published
@@ -88,12 +93,11 @@ version of Zulip. We work extremely hard to make sure Zulip is stable
 for self-hosters, has no regressions, and that the [Zulip upgrade
 process](../production/upgrade.md) Just Works.
 
-The Zulip server and clients apps are all carefully engineered to
+The Zulip server and client apps are all carefully engineered to
 ensure compatibility with old versions. In particular:
 
 - The Zulip mobile and desktop apps maintain backwards-compatibility
-  code to support any Zulip server since 4.0. (They may also work
-  with older versions, with a degraded experience).
+  code to support any Zulip server version from the last 18 months.
 - Zulip maintains an [API changelog](https://zulip.com/api/changelog)
   detailing all changes to the API to make it easy for client
   developers to do this correctly.
@@ -107,7 +111,6 @@ As a result, we generally do not backport changes to previous stable
 release series except in rare cases involving a security issue or
 critical bug just after publishing a major release.
 
-[blog-major-releases]: https://blog.zulip.com/tag/major-releases/
 [upgrade-from-git]: ../production/upgrade.md#upgrading-from-a-git-repository
 
 ### Security releases