Updated: Documented running the engine from its archive, and corrected the cache warming notes.

phar.md described switching the runtime onto the archive as "set EXP_ENGINE_PHAR
in the server's environment", which was true and not useful: nothing set it, so
the archive could be built and inspected but never run. It now documents the
ServerSettings/EnginePhar setting, why the value has to reach the server as an
environment variable rather than an argument, that a missing archive stops the
server rather than falling back, and that switching either way needs the caches
cleared.

It also records why it could not work before the 0.0.4.8 server release: the
compatibility layer rewrites header() and setcookie() as each file is included,
because under the CLI SAPI they do nothing on their own, and it wrapped only the
file:// scheme. Code inside the archive skipped it, so the site rendered
correctly and sent almost no headers -- nothing cacheable, and no way to sign
in. Anyone meeting that symptom should check the server version first.

http-caching's companion gains three corrections to the cache warmer, all of
which reported success while they were happening: it warmed addresses nobody
asks for, it renewed nothing because a plain request returns a hit and leaves
the expiry alone, and it then became the reason pages were slow because
refreshing means rendering. Also that the response cache's default skip cookies
name PHP's and Qbix's session names rather than this application's, and that
signing in did not work over HTTP/2 at all before 0.0.4.7.

Updated: Updated the web server requirement to ~0.0.4.8, so the engine can run from its archive.

The compatibility layer rewrites header(), setcookie() and their kin as each
file is included, because under the CLI SAPI those functions do nothing on
their own. It did that by wrapping the file:// scheme, and code included
through phar:// never passed through it.

So running the engine out of dist/engine.phar produced a site that rendered the
right pages and sent almost no headers with them -- no Cache-Control, so
nothing could be cached and every request was rendered, and no Set-Cookie, so
signing in was impossible. Nothing was logged, because nothing failed.

With the release the archive behaves: every header present, the response cache
working, sign-in setting a session, and the front page unchanged at about 75ms.

Updated: Renamed the engine panel and made a stale archive say how to fix itself.

The heading is "Phar App Engine", which is what the section is about.

"Archive is current: NO -- archive 6.0.15stable-aae2c57d, working tree
6.0.15stable-a9ff7b25" told a reader that two version strings differ and left
them to work out which was which, whether it mattered, and what to do. It now
says why, and what to run:

    Archive is current: no
      Why: it was built from commit aae2c57d and the working tree is now at
      a9ff7b25; the working tree has uncommitted changes, so a rebuild will
      capture whatever is on disk right now.
      To fix: php bin/php/phar.php build --allow-root-user, then restart the
      application server so it opens the new archive.
      The site is running from this archive, so what is on disk is not what is
      being served.

The two shapes of staleness are distinguished, because they call for different
thought: built from an older commit, or built from this commit before files
were edited. The last line changes with whether anything is actually running
from the archive -- a stale archive nobody is using is a note, and a stale
archive serving the site is not.

Added: Added a service setting for running the engine out of the archive.

The bootstrap loads the engine from dist/engine.phar only when the
EXP_ENGINE_PHAR environment variable names an archive that exists, and nothing
set it. The archive could be built and inspected but never actually run:
testing it meant exporting the variable by hand into whatever started the
server, and Setup > System information could only ever report "Individual files
on disk".

ServerSettings/EnginePhar takes disabled (the default), enabled, or a path. The
value is exported into the server's environment at launch, because autoload.php
reads it before it has parsed anything and therefore before any command line
argument could be consulted.

An archive that is not there stops the server from starting rather than falling
back to the files on disk, because a silent fall back is indistinguishable from
success and the difference only shows up much later. The chosen engine is now
reported by the status verb for the same reason.

Two things to know before turning it on, both measured here:

- It is slower. The same front page served in 74ms from the files on disk and
  1.2-1.7s from the archive, and that was with the response cache doing nothing
  because of the point below.

- Switching engines poisons the caches. Pages rendered while the archive was
  active came back afterwards with almost no headers -- no Cache-Control, no
  Content-Type -- so nothing could be cached and every request was rendered.
  A full cache clear put it right. Clear the caches when switching either way.

Updated: Updated the web server requirement to ~0.0.4.7, so signing in works over HTTP/2.

Every cookie a script set was dropped over HTTP/2. A worker builds them with
setcookie() in its own process, so a pooled response carries them separately
from its headers, and that path only ever read the headers.

Signing in to the admin was therefore impossible over HTTP/2: the login
answered 302 to the right place and set no session, so the next request arrived
anonymous and bounced back to the form. It went unnoticed because a browser
already holding a session carried on working, and a session obtained over
HTTP/1.1 is equally good over HTTP/2 -- only a fresh sign-in on a connection
that had negotiated h2 could see it, which is every private window.

Also stops SERVER_NAME carrying the port. It is the host; SERVER_PORT is the
port, and applications do arithmetic on the difference.

Updated: Lowered the cache warmer to one request at a time so it stops slowing the site.

Since the warmer started asking the server to renew entries rather than read
them, every page it touches is rendered, so a cycle is real load rather than a
few hundred cache hits. Two at a time was still enough to be felt: an admin page
measured 141-287ms between cycles and 679-1146ms during one, and the minute a
cycle ran carried 290 requests of its own.

One leaves the rest of the workers free and still finishes far inside the cache
lifetime.

This is the second time the warmer turned out to be what made a page slow. It
exists to spare visitors the slow path, so it must never be the reason one
waits.

Updated: Made the engine panel say plainly which engine is running.

The panel listed the archive, its version and whether it matched the working
tree without ever stating on the first line that none of it was in use, so it
read as though the archive might be running and might be stale. It says so now,
and says why: the archive is used only when the EXP_ENGINE_PHAR environment
variable points at one.

"Matches working tree: NO" was also alarming for no reason when nothing is
running from the archive. It is now "Archive is current", and when the archive
is idle it adds that it should be rebuilt before switching to it.

"unregistered (phar.readonly on)" was two unrelated facts on one line, read as
one. The stream wrapper being unregistered is a deliberate hardening choice --
with it registered, a file that is both a valid image and a valid archive can
be executed through a phar:// path, and this installation accepts image uploads
by design. phar.readonly is a separate setting about whether an archive can be
written. They are two rows now, and the first explains itself.