Added: Added config commands to exp:velocity, writing to the file the server actually reads.

  exp:velocity config list [Block]              every setting, and which are ours
  exp:velocity config get <Block> <Variable>    one value
  exp:velocity config set <Block> <Variable> <v>
  exp:velocity config unset <Block> <Variable>  back to the packaged value
  exp:velocity config paths                     which file is which

That last verb exists because of what building this turned up. Three files look
like the server's configuration and only one is:

  settings/velocity.ini                     the source of truth
  settings/override/velocity.ini.append.php this installation's own choices
  var/tmp/velocity-server.json              generated on every start
  /etc/qbix/qbix.json                       read by nothing at all

The generated file is the one anybody would find and edit, and it is rewritten
from the settings above on every start, so a change there survives until the
next restart. /etc/qbix/qbix.json is referenced by no code in the server or in
this installation. Two of the three places a person would naturally look
discard what they are told.

So writes go through eZINI to the override, leaving the packaged defaults
intact and this installation's choices visible as a short list rather than
buried in a copy of the whole file. Reads come from the merged view, so what
you are shown is what the server would use, and the listing marks which values
were chosen here.

A setting velocity.ini does not define is refused. A variable name that is
almost right is otherwise completely silent: the file is written, the value
sits in it, and the server goes on using the default.

The override is written 0600, since it names a private key among other things,
and the INI caches are dropped afterwards -- without that, set reported success
and list immediately afterwards showed the old value, which is worse than
declining to report one.

Verified end to end: set, read back, unset, and the override file byte for byte
identical to its backup afterwards.

The autoload array is regenerated because the new class lives in
kernel/classes, which needs -k rather than the -e used for extensions.

Fixed: Fixed graceful reporting a reload it had not performed.

It sent the reload and then waited for the ports to come back. A re-exec keeps
the listening socket open across it -- that is the whole point of the verb --
so from outside the ports never went away, the first check always passed, and
the reload was reported as done whether or not anything had happened. It
reported success for a complete no-op: parent and every worker carried on with
the code they were already running while the operator believed the new code was
live.

The parent keeps its pid across a re-exec, because that is what exec does, so
the parent cannot witness this either. The workers can: a re-executed parent
forks a fresh set, and a changed set of children is the one observable fact
that means it really happened. childIDs() reads them, and graceful now requires
the old ones gone, new ones up, and the ports answering before it says so.

Verified on this installation: graceful returns "reloaded" in 6s with the
parent keeping its pid and the workers replaced, and the site answering
throughout. Before this it returned in under a second having done nothing.

Updated: Updated the theme and web server requirements to versions that exist.

sevenx-themes-media moves to ~1.5.11, which stops a keyword attribute ending
the request. Searching the site answered only with "array_map(): Argument #2
must be of type array, eZKeyword given"; the same five lines also built an
empty tag list for every keyword attribute, silently, and fixing only the crash
would have left that in place.

The web server requirement was ~0.0.4.22, and there is no such release: that
tag was cut while the release pipeline was skipping its own release job, so the
floor named a version nobody could install. It now names 0.0.4.24, which is the
newest that exists. The tilde admits 0.0.4.25 the moment it publishes, and that
is the one carrying the containment, framing and HTTP/2 fixes.

share/filelist.md5 is refreshed for composer.json alone, which is the only file
this changes.

Updated: Updated the web server requirement to ~0.0.4.20, so the request that fills the response cache is served the same page as every request after it.

Minification ran when a page was stored, so the response that filled the cache
went out unminified while every response after it was minified. On this
installation that was 95,086 bytes against 70,061 -- the same page in two sizes
depending on which visitor happened to rebuild it, and a quarter more bytes for
the one who did.

A benchmark of a hundred requests reported ninety-nine of them as failed, which
was a length comparison rather than an error, and carried a one second outlier
that was the oversized render. Both are gone: one document length, no failures.

Added: Added a section explaining how Exponential is served, and introducing Exponential Velocity as the fast option alongside the traditional web servers.

The README named a few web servers in passing and said nothing about how to
choose between them, or that this release ships one of its own.

The new section lists the servers Exponential runs behind -- Apache, Nginx,
LiteSpeed and OpenLiteSpeed, Caddy, IIS, lighttpd, H2O and Traefik -- with how
each rewrites a URL, since that is the one thing a server has to do for readable
addresses to work. The PHP built-in server is listed separately and marked as
development only, because people do expose it.

It then explains Velocity: a server bundled with this release that keeps the
application loaded between requests instead of starting it fresh for every one,
with the measurements stated so a reader can tell what they mean. 0.36ms is the
server's own work on a cached page, taken as a median rather than a best case;
8,941 requests a second was measured on a twelve-core machine with no errors at
any concurrency tried; and "repeat visits never touch the network" is the
optional navigation cache, which is a property of the visitor's browser rather
than of the server.

The section that matters most is the one saying most of the speed is not
Velocity. The cache and application fixes in this release -- conditional
requests answered properly, a validator derived from content, one rebuild per
expiry instead of one per waiting visitor, remembered not-founds, pages no
longer padded with template indentation -- apply wherever Exponential runs.
6.0.15 is fast under load on Apache or Nginx too, and a reader should not come
away thinking otherwise.

Two warnings are included because both cost real time to discover: workers hold
the application in memory, so a template or settings change needs a restart
rather than a cache clear; and a single server process serving several sites is
a routing convenience, not a security boundary.

Updated: Updated the web server requirement to ~0.0.4.19, which makes a stale committed archive fail the test suite rather than a release.

bin/qbixserver.phar is committed and is what a Composer install runs, so an
archive built from older sources ships working source and stale behaviour to
anyone running from the archive rather than from src/. The check for that has
existed and the release workflow gates on it; what was missing is the local
suite, which selects tests by naming convention that this one does not follow.

Editing a source file and leaving the archive alone now fails the suite and
prints the rebuild command.

Updated: Updated the web server requirement to ~0.0.4.18, which stops a worker holding connections that belong to other visitors.

A forked worker inherited the parent's entire descriptor table. It needs one --
its half of the socket pair the pool made for it -- and the child closed exactly
that one, keeping the listening socket, the TLS listener, every client
connection open at that instant, and the parent's end of every other worker's
socket pair. A worker serving one request therefore held another visitor's
connection and could read from it, with no multi-tenancy involved.

Measured on this installation before and after, with sixteen workers:

    processes holding the listening sockets   17  ->  1
    socket descriptors per worker    3,4,5,6 (mean 10)  ->  1

The ascending count before the fix was each worker inheriting the socket pairs
of every worker forked before it.

0.0.4.18 rather than 0.0.4.17 because the latter was tagged before the bundled
archive had been rebuilt, so its source carried the fix and its archive did not.