Issue #1698 — executions.status code outside the config became a bogus "" metric

Symptom

tlTestPlanMetrics::getExecCountersByExecStatus() resolved the executions.status code → verbose status map without a guard, so any row whose status code is not a key of config results.status_code (cfg/const.inc.php:376) was written under the empty-string array key '' and raised one E_WARNING Undefined array key per call. The modern Metrics Dashboard BFF counts every key that is not total/not_run as executed, so the bogus bucket inflated executed/progress while no status column could explain it — a payload that contradicts itself, published with 200 {"status":"ok"} and no user-visible error.

Measured pre-fix (project 1, plan 2, 8 active TCs, 4 executions of which 2 truncated to ''):

getExecCountersByExecStatus() = {"total":8,"":"2","blocked":"1","failed":"1","not_run":"4"}
overall.statuses             = {"":2,"blocked":1,"failed":1,"not_run":4,"passed":0}   executed:4  progress:50%
events                       = E_WARNING Undefined array key "" - tlTestPlanMetrics.class.php - Line 1083

Root cause chain

1. lib/functions/tlTestPlanMetrics.class.php:1078 builds array_flip($this->map_tc_status).
2. :1083 $statusCounters[$codeVerbose[$code]] = $elem['exec_qty']; — $code is whatever the SQL GROUP BY status (:1070-1073) found in the DB, so an unknown code yields null → key ''. The = also let two bad codes overwrite each other instead of aggregating.
3. api/metrics/index.php:281-292 treats every non-total/not_run key as executed.
4. The same unguarded lookup existed on the platform branch (api/metrics/index.php:248).

Fix

• Metric layer (tlTestPlanMetrics.class.php:1077-1110): an unknown code resolves to the explicit unknown verbose status (a real status in $tlCfg->results['status_label'], code u), accumulated with += after an isset() init; total keeps counting every row so active still matches the plan's assigned TC count. The anonymous E_WARNING is replaced by one aggregated logWarningEvent() per call, naming the offending codes and quantities (activity=EXEC_STATUS, object=testplans/<id>).
• BFF (api/metrics/index.php): platform branch guarded identically; the project total for non-renderable rows is accumulated in $unknownTotal ($total has no unknown key until the display set gains it) and a per-plan $planUnknown feeds the PLAN level overall.statuses; the unknown status is appended to the payload's status_set only when some plan really reports such rows, so a healthy project keeps byte-identical output.
• Client (gui/templates/results/metricsDashboard.html + all 10 gui/templates/i18n/*.json): STATUS_COLORS/STATUS_KEYS gained unknown and one new key md.statusUnknown (legacy $TLS_test_status_unknown wording) — the grid and the progress bars are data-driven off status_set, so no restructure was needed.
• A code review of the first attempt added the case that the reviewer found: codes whose verbose status is not in status_label_for_exec_ui (x not_available, a all) are also not renderable, so they are collapsed into the same unknown counter. Before that, x still raised E_WARNING Undefined array key "not_available" at api/metrics/index.php:276.

Post-fix result

status_set  = [not_run, passed, failed, blocked, unknown]
statuses    = {unknown:2, blocked:1, failed:1, not_run:4, passed:0}   executed:4   (sum 4 == executed 4)
progress bars: Overall 50% [4/8] · Not Run 50% · Passed 0% · Failed 12.5% · Blocked 12.5% · Unknown 25%
Event Viewer : one aggregated "METRICS: 1 execution status code(s) not defined in config
               results.status_code, counted as unknown on test plan 2: '' => 2" (activity EXEC_STATUS)
healthy data : identical payload to pre-fix, 0 new events rows

Known follow-ups (measured, deliberately out of scope of this single-bug run)

• lib/results/metricsDashboard.php:228-238 (legacy Smarty twin) has the same unguarded pattern.
• getStatusForReports() (tlTestPlanMetrics.class.php:1337-1349,1372-1384) builds its map from status_label_for_exec_ui only, so the per-platform report charts (api/reports/index.php?action=charts_data) still drop such a row while helperCompleteStatusDomain() counts it in total.
• lib/results/overallPieChart.php:39-47 iterates $series_color without initialising it — a result set whose statuses all lack a chart colour raises foreach() argument must be of type array|object, null given.