Basic Firewall 1.0.0-rc.4

Fourth release candidate for 1.0.0. Published as a GitHub pre-release, so
the releases/latest/download URL does not serve it; install it by its own URL.
It hardens exception mode on the wp-config.php path so a verdict can never
serve the page (#34), makes the pass cookie name a setting both evaluation
paths honour (#35), and bundles kanopi/firewall 2.34.1, which keeps every
response the library writes out of caches. What changed since 1.0.0-rc.3 is
below.

Changed

• Requires and bundles kanopi/firewall 2.34.1 (was ^2.34). The release
  zip bundles 2.34.1, namespace-scoped. In block mode the library answers
  itself, and every response it writes now carries the full no-cache set
  (kanopi/firewall#417,
  #418): the challenge
  interstitial, block pages (which sent no cache header at all), lockdown,
  redirects, and the challenge-verify JSON that sets the pass cookie (none
  either). The interstitial ignores a double submit while one is in flight.
  A spent challenge solution coming back from a different client, which is
  what a cached challenge page looks like, is now logged at warning; the
  same client twice stays at info. No configuration changes.
• The mu-plugin loader is 1.2.0; the plugin replaces the installed copy
  on the next admin, cron or WP-CLI request. See Fixed.
• The pass cookie name set on the Challenge screen is now what both
  evaluation paths issue and check (#35). The compiled file always names
  the cookie explicitly (the field's value, trimmed; bfw_pass by default)
  rather than leaving it to the library's default, and in exception mode
  the runner sets the pass under the compiled name instead of re-reading
  settings. The field is required: an empty or malformed name is refused
  with a notice and nothing is saved. Upgrade routine 11 recompiles on the
  first request after updating. Changing the name invalidates passes
  already issued, so each visitor holding one is challenged once more.

Fixed

• A solved challenge that keeps being challenged is now explained in
  exception mode (#35). Some hosts or edge caches only forward cookies
  whose names match their own rules, so the pass never comes back; the fix
  is to set a name the host forwards (see Changed, and the README). A
  visitor challenged within two minutes of solving one, without the pass, is
  now told the verification cookie did not come back, and a warning is
  logged. It uses a short-lived, unsigned marker cookie named after the pass
  cookie (<name>_solved), so a prefix chosen for the host applies to it
  too; the interstitial stays no-store. block mode is unchanged, because
  the library renders that page itself.
• An exception mode verdict on the wp-config.php path can no longer
  serve the page (#34). Every route by which the early path could fail
  open on a challenge, redirect or block now ends in a plain 503
  "Verification required" refusal instead: the responder throwing (the
  verdict used to be handed to the runner, which runs after a page cache, or
  not at all), the responder returning as though the request may continue
  (it used to return true straight to wp-config.php), the responder
  missing from the plugin copy, and a verdict thrown by the other library
  copy (scoped or unscoped), which the responder took for a firewall failure
  and let through. Each is logged to the PHP error log at warning. The runner
  also refuses, and reports to Site Health, any request the early path
  recorded a verdict on and did not answer, so an older bootstrap.php
  still required from wp-config.php cannot fail open silently; the mu-plugin
  loader (now 1.2.0) loads the plugin for that case. The report's exact
  setup, a per-rule ALTCHA challenge on a WordPress-routed page, did not
  reproduce locally on DDEV in either the zip or a Composer install; it is
  now covered over HTTP.
• Every response the plugin writes carries the full no-store set from
  kanopi/firewall#418:
  Cache-Control: private, no-store, no-cache, must-revalidate, max-age=0,
  Pragma: no-cache, Expires: 0, Surrogate-Control: no-store and
  CDN-Cache-Control: no-store, each replacing any earlier header of the
  same name. That is the challenge interstitial, block, lockdown and redirect
  answers, and the solved-challenge JSON and redirect. They carried only
  no-store and Pragma, which Pantheon's edge caches anyway. The set is
  the library's NoStore::HEADERS.