QFw: keep QFw's log lines in Loki, beside the traces

[DougSO]

The cluster side of QFw's logs tier (openQSE/QFw#123 and #124).

• Loki (grafana/loki:3.7.8) joins the stack with its own volume, two weeks of retention like Tempo, and OTLP ingestion. telemetry/loki.yaml keeps service.name, qfw.component.role and qfw.device.name as stream labels; everything else on the resource, and trace_id, span_id, severity_text and the code location, ride as structured metadata on each line.
• The collector gets a logs pipeline: the OTLP receiver, the same resource trimming as the metrics pipeline (without it Loki would index one stream per client process), and otlphttp to Loki's /otlp endpoint. The 0.162 contrib build has no Loki exporter any more; Loki's native OTLP is the hop.
• Grafana: a Loki data source; the Tempo source's trace-to-logs link runs {service_name=~"qfw-.+"} | trace_id="<the span's trace>", deliberately not filtered by the span's service so the client's lines show under a QPM span too; the Loki source's derived field opens a line's trace in Tempo. QFw Trace gains a logs panel under the waterfall; QFw Jobs a "Recent warnings and errors" panel. Provisioning files expand $VAR, so the run-time variables are written $$.
• The overlay sets QFW_TELEMETRY_LOGS=debug, the tier at which QFw writes a job's story, and qfw-site-services forwards it. do_telemetry.sh knows the fifth container and its volume for purge. The README has a Logs section, the variable, a check and a troubleshooting entry.

Verified on the live stack: compose validates; the five containers come up; a local plane and the site fake-IQM QPM, run from a QFw with #124, put their lines in Loki with the right labels and no DEFw chatter at debug; Grafana's Loki source answers; the fallback snapshots still build with the new panels.

One honest limit, for the fake IQM: nothing it logs sits inside a job's spans today (its two per-job lines belong to the device query the client makes before the job starts), so its traces show no lines yet. Real drivers log inside their execute spans and will. A few milestone lines from QFw's instrumentation layer would give every backend a story under the waterfall; that is a QFw decision, raised separately.

The live stack carries these files uncommitted until the catch-up; the site services report once the image carries #123 and #124.

[DougSO]

The limit noted in the description is now addressed on the QFw side by openQSE/QFw#125: the instrumentation layer writes five story lines per job inside the job's spans, and the tier re-attaches its handler after DEFw's log-level setup strips the root logger, which had left the tier silently dead in every service process. With #124 and #125 in the image, a fake-IQM trace shows three QPM lines and QFw's run-path lines under its waterfall; verified on this stack with 318 stitched lines over 20 jobs.