Read query times in the display timezone, and stop capping result width

Two things that made reading logs harder than it needed to be.

Query input: the API accepts an absolute time only if it is quoted AND
carries an explicit offset, so someone reading logs in America/Denver
who wanted "9am today" had to convert to UTC in their head and remember
the quotes. Now a time typed without an offset is read as wall-clock
time in that reader's display timezone and converted to the instant it
names; anything with an explicit offset is taken at its word, and
relative ranges never depended on a zone.

This widens what's accepted rather than reinterpreting anything -- every
naive form now handled is one the parser rejects outright today, so no
query that works now can change meaning. The conversion happens before a
query is sent *or saved*: a stored dashboard range becomes an explicit
instant, because storing "2026-08-22 10:00" would mean 10am in whatever
zone each viewer sat in, and one shared dashboard would show two people
two different windows.

It also fixes two bugs that predate the timezone work. injectTimeRange
emitted absolute values unquoted, which the parser rejects -- so zooming
a time-series chart into a range, and clicking a chart to drill down,
both produced a syntax error on every panel. Both fed an ISO string
straight into that unquoted path.

Width: the query page's 64rem cap is gone, so the query bar and results
table use the whole window -- a log table is the widest thing in this
app and that cap was the horizontal scrolling. Prose keeps a readable
measure, since full-width paragraphs are harder to read, not easier.

Ambiguous local times -- the hour that repeats when clocks go back, the
hour skipped when they go forward -- resolve to one instant. That is
inherent to naming a moment by wall clock; an explicit offset sidesteps
it. Documented at the conversion.

web/README.md

@@ -49,9 +49,18 @@ line see the same instant written two ways.
   *browser's* zone with no way to override it, which would put a chart's
   clock out of step with the table beside it.
 
-The one place the UTC baseline is still visible to a user is query input:
-`earliest=`/`latest=` are parsed as UTC regardless of this setting. The
-Settings page says so explicitly rather than leaving it to be discovered.
+Query *input* follows the same setting: an absolute time written without
+an offset (`earliest=2026-08-22 09:00`) is read as wall-clock time in the
+reader's zone and converted to UTC before the query is sent -- see
+`src/lib/querytime.ts`. Anything with an explicit offset is taken at its
+word, and relative ranges (`-24h`) never depended on a zone.
+
+That conversion happens before a query is sent *or saved*, so a stored
+dashboard range is an explicit instant rather than "10am, whoever you
+are" -- otherwise one shared dashboard would show two different windows
+to two people. The API itself is unchanged and still accepts only quoted
+RFC3339 with an offset; everything this adds is a form it rejects today,
+so no query that works now can change meaning.
 
 ## Building & running