hardening: validate MySQL result column counts before row[index] access

[somethingwithproof]

Summary

Several hot paths index MySQL rows by fixed offsets (for example row[36]) without validating result column count first.

Why this matters

• Schema drift, query edits, or partial result sets can cause out-of-bounds row access.
• This can lead to NULL dereference, corrupted state, or undefined behavior during polling.
• Defensive checks should fail closed with explicit logging.

Evidence

• poller.c host-loading path indexes row[0]..row[36].
• util.c update batching path indexes many fixed columns in sequence.
• Current logic checks row[i] != NULL but not whether i is within the returned field count.

Scope

• Add mysql_num_fields(result) guards before any fixed-index row access loops.
• Define expected column counts next to each query.
• On mismatch: log precise error (query context + expected/actual count) and skip/abort safely.

Proposed implementation

1. For each fixed-index query, define EXPECTED_*_COLS constant.
2. Validate field count immediately after query success and before fetch loop.
3. Return safely on mismatch, with actionable log message.
4. Add helper macro/function to reduce repeated boilerplate.

Acceptance Criteria

• All fixed-index result consumers validate field count first.
• No direct row[N] access paths remain without an upstream width check.
• Error path is non-crashing and explicit in logs.
• Polling continues for unaffected hosts/work items.

Out of scope

• Full ORM or query-builder refactor.
• Changing schema or query semantics.

[somethingwithproof]

Addressed in PR #511. Added mysql_num_fields() validation after poller_item SELECT query. Checks column count matches expected (21 with output_regex, 20 without) before accessing row[N] indices.