Fixed #32065 -- Restored leading dot to CSRF_COOKIE_DOMAIN examples.

Partially reverts afd375fc343baa46e61036087bc43b3d096bb0ca.

Thanks to Tim Graham for review.

docs/ref/csrf.txt

@@ -276,10 +276,10 @@ The CSRF protection is based on the following things:
    enough under HTTP.)
 
    If the :setting:`CSRF_COOKIE_DOMAIN` setting is set, the referer is compared
-   against it. This setting supports subdomains. For example,
-   ``CSRF_COOKIE_DOMAIN = '.example.com'`` will allow POST requests from
-   ``www.example.com`` and ``api.example.com``. If the setting is not set, then
-   the referer must match the HTTP ``Host`` header.
+   against it. You can allow cross-subdomain requests by including a leading
+   dot. For example, ``CSRF_COOKIE_DOMAIN = '.example.com'`` will allow POST
+   requests from ``www.example.com`` and ``api.example.com``. If the setting is
+   not set, then the referer must match the HTTP ``Host`` header.
 
    Expanding the accepted referers beyond the current host or cookie domain can
    be done with the :setting:`CSRF_TRUSTED_ORIGINS` setting.

docs/ref/settings.txt

@@ -318,7 +318,7 @@ Default: ``None``
 The domain to be used when setting the CSRF cookie.  This can be useful for
 easily allowing cross-subdomain requests to be excluded from the normal cross
 site request forgery protection.  It should be set to a string such as
-``"example.com"`` to allow a POST request from a form on one subdomain to be
+``".example.com"`` to allow a POST request from a form on one subdomain to be
 accepted by a view served from another subdomain.
 
 Please note that the presence of this setting does not imply that Django's CSRF