Basic Firewall 1.0.0-rc.2

Second 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.
What changed since 1.0.0-rc.1 is below; the full description of the plugin is
under 1.0.0-rc.1.

Added

• Naming the Composer autoloader for the wp-config.php early path. An
  'autoloader' option to basic_firewall_evaluate(), and a
  BASIC_FIREWALL_AUTOLOADER constant, for a site-level Composer install whose
  vendor-dir is not beside the WordPress root. The option beats the constant.
  The plugin's own vendor/ still comes first, so a release zip keeps running
  its scoped copy of the library whatever a site names.
• The snippet on the Status screen, in Site Health and in
  wp basic-firewall status carries the 'autoloader' line when the plugin is
  running from a site-level Composer install whose autoloader the bootstrap
  would not find. The path is read off the library actually running, and
  written relative to ABSPATH when it is inside it.
• wp basic-firewall status warns with the reason when the wp-config.php
  snippet is present but not evaluating, and prints the snippet when the
  reason is a missing or unreadable autoloader.

Changed

• Requires and bundles kanopi/firewall 2.33.2 (was ^2.33.1). The release
  zip bundles 2.33.2, namespace-scoped.

Fixed

• A custom Composer vendor-dir left the early path doing nothing (#26).
  The bootstrap looked only in the plugin's vendor/ and beside the WordPress
  root, so a site with "vendor-dir": "web/wp-content/mu-plugins/vendor"
  always ended in no-autoloader and was evaluated after
  advanced-cache.php. It now also uses the autoloader the site names, and a
  library wp-config.php already loaded above the snippet.

• A named autoloader that cannot be read is reported as
  autoloader-unreadable, naming the file and whether the option or the
  constant named it, instead of falling through to the guessed locations.

• The no-autoloader reason in Site Health and on the Status screen says how
  to fix it, and both print the snippet beside it rather than a rebuild button
  that cannot help.

• A rate limit can count a form field, cookie or query parameter whose name
  has capitals in it. Before 2.33.2 the library lower-cased every key
  component, so post.userName read a field called username, found nothing,
  and put every request in one counter; the rule screen refused such a key for
  that reason. 2.33.2 keeps the case of the name after post., cookie. and
  query., and the plugin now stores and compiles it as typed. The prefix and
  a header name are still lower-cased, exactly as the library does it, and the
  refusal and its message are gone.

  No stored limit changes counter, and there is no upgrade step. Every
  path to the library runs the rate limit validator — the rule screen, the
  importer and the settings service on the way in, and the compiler again on
  the way out, for anything written straight into the option — which
  lower-cased every key and refused a capitalised POST, cookie or query name.
  So every key the library has ever been handed is lower case, and 2.33.2
  hashes it to exactly the counter it used before. The only difference is that
  a rule written straight into the option with such a name, which the compiler
  used to skip and report, now compiles. Check that a field name in a key matches the form's spelling exactly:
  post.username against a form posting userName still reads nothing.