fix(confidence): stop an unreadable confidence from reading as 0.0

[CaptainMittens]

What this fixes

strtod answers 0.0 for text it cannot read. Two places treat the number
it returns as a real confidence, so a property blob carrying a malformed
value — "confidence":null, an empty string, anything non-numeric — came
back as a recorded confidence of zero. Zero is a meaningful value in
both places, so nothing looked wrong.

1. src/graph_buffer/graph_buffer.c — the wrong blob wins a merge

edge_props_confidence answers CBM_EDGE_CONF_ABSENT (-1) for an edge
that carries no confidence, so that any real confidence outranks it. The
merge in edge_props_should_replace is a plain comparison:

if (inc != cur) {
    return inc > cur;
}

A malformed value answered 0.0, which beats -1. So a blob whose
confidence the code cannot even read displaced a clean stored blob that
simply carried no confidence at all. The stored "strategy" went with it.

The function's own doc comment already promised the correct behaviour:

/* Read "confidence":<double> out of an edge property blob. Absent/unparseable
 * reads as -1 ... */

Only the absent half was true.

2. src/mcp/mcp.c — "not recorded" published as 0.00

bfs_edge_evidence_for_hop sets the confidence to -1.0 first, and the
emitter publishes any value of 0 or more as a recorded number
(%.2f in the text renderer, a real in the JSON renderer) and - / null
below zero. A malformed value therefore printed as 0.00.

That is the one number the surrounding code works to keep meaningful. A
caller reading 0.00 cannot tell "the resolver was certain this call is
wrong" from "nobody wrote a number here".

The fix

Both sites now pass an end pointer to strtod and keep the absent sentinel
when the pointer never moved — nothing was read. This is the shape
src/store/store.c:402 already uses.

const char *value = p + sizeof(conf_key) - SKIP_ONE;
char *end = NULL;
double conf = strtod(value, &end);
if (end == value) {
    return CBM_EDGE_CONF_ABSENT;
}
return conf;

Only the unreadable case changes. A real 0.0 still reads as 0.0
everywhere, and every existing confidence test passes untouched.

Tests

Two tests come with the change. Both were seen failing before the fix and
passing after — not written after the fact.

Test	File
gbuf_edge_props_unreadable_confidence_does_not_displace_absent	tests/test_graph_buffer.c
tool_trace_path_unreadable_confidence_reports_not_recorded	tests/test_mcp.c

Each carries positive controls, so a later failure points at the confidence
and not at a broken request. The mcp test asserts the hop and its readable
strategy class still come through, then asserts the output holds no
0.00.

Red, before the fix:

258 passed, 2 failed, 6 skipped
  FAIL tests/test_mcp.c:3398: strstr(ev_txt, "0.00") is not NULL
  FAIL tests/test_graph_buffer.c:261: ASSERT(strstr(edges[0]->properties_json, "\"strategy\":\"lsp\"") != NULL)

Green, after the fix:

260 passed, 0 failed, 6 skipped   (EXIT=0)

Checks run

Command	Result
make -f Makefile.cbm test-focused TEST_SUITES="graph_buffer mcp"	260 passed, 0 failed, 6 skipped — exit 0
make -f Makefile.cbm lint-ci	=== CI linters passed === — exit 0
make -f Makefile.cbm cbm	exit 0
make -f Makefile.cbm test	7633 passed, 2 failed, 8 skipped

The two full-suite failures are in tests/test_cli.c (lines 1749 and 6725)
and reproduce on a clean tree without this change. Both print
error: one or more agent cleanup operations failed, so they depend on the
coding agents installed on the machine rather than on anything here.

How this was found

By scanning for siblings of the parse bug fixed in #1875 — the same shape
of "a parse reports success while the input stays unread". These two are
the confidence-sentinel pair from that scan. Four more candidates remain
and will come as separate pull requests.

Checklist

• Signed off with git commit -s (DCO)
• make -f Makefile.cbm test run
• make -f Makefile.cbm lint-ci run
• New behaviour covered by a test

Fixes #1980

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[CaptainMittens]

Context that is not visible from this PR on its own: it is one of four from a single scan.

After #1875 I went looking for siblings of its shape — a parse reports success while the input stays unread. The scan found six. Four are filed: #1875 (the cypher parser), this one (strtod), #1880 (atoi/atol on environment settings), and #1881 (strtoll on span timestamps).

They make the same argument as #1922: an input the code cannot read becomes a plausible value, and nothing downstream can tell it from a real one. The silence is the harm.

Here that value is 0.0, and it is worse than a wrong number. 0.0 outranks the -1 absent sentinel in edge_props_should_replace, so a blob whose confidence could not be read displaced a clean stored blob that simply carried none — and took the stored strategy with it. The function's own doc comment already promised the right behaviour; only the absent half of it was true.

Two more candidates from that scan are not filed yet. Would you rather they came as their own PRs, or folded into one of these?