web: fix whitespace-fragile extract_bool_value in request_handler

[oharboe]

extract_bool_value searched for the literal string "value":true with no tolerance for whitespace after the colon, unlike every other extract_* helper in the same file. If a client sent pretty-printed JSON (space after ':'), the function silently fell through to the integer fallback path. Rewrite to skip whitespace consistently, matching the pattern used by extract_int and extract_float_or.

[oharboe]

@maliberty just an experiment: I asked claude to find low churn maintainability issues in recent pull request merges.

Close if not useful.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[gemini-code-assist]

Code Review

This pull request refactors the extract_bool_value function in request_handler.cpp to manually parse JSON values and include a fallback for integer-based booleans. The review feedback suggests extracting the shared parsing logic into a common helper function to reduce duplication and recommends verifying the full boolean literals ('true' and 'false') rather than just the first character to ensure parsing robustness.

[gemini-code-assist]

This logic for finding the key, locating the colon, and skipping whitespace is identical to the implementation in extract_int and extract_float_or. Consider extracting this into a common helper function (e.g., find_value_start) to reduce code duplication and improve maintainability. Note that helper logic should be defined as a free function in a namespace rather than as a local lambda.

References

1. To improve maintainability and reduce redundancy, extract duplicated logic into a helper function.
2. Helper logic should be defined as a free function in a namespace rather than as a local lambda within a function.

[gemini-code-assist]

The current implementation only checks the first character ('t' or 'f') to determine the boolean value. This is significantly less robust than the previous implementation and could lead to incorrect parsing if the value starts with these letters but isn't a valid JSON boolean (e.g., "value": "total" would be parsed as true). It is better to check for the full literal.

Suggested change

	if (pos < json.size() && json[pos] == 't') {
	return true;
	}
	if (json.find("\"value\":false") != std::string::npos) {
	if (pos < json.size() && json[pos] == 'f') {
	return false;
	}
	if (pos < json.size() && json.compare(pos, 4, "true") == 0) {
	return true;
	}
	if (pos < json.size() && json.compare(pos, 5, "false") == 0) {
	return false;
	}

[maliberty]

More bother than benefit as only the web client generates requests

[oharboe]

goes to show, better you run such a claude triage locally than me trying to do it for you with the added bother of a PR. to the extent that it has value in the first place