Audit panic paths, split config domains, and align release metadata

[EvalOpsBot]

Summary

• harden the highest-risk production parser panic paths by removing capture-group unwrap/expect usage in LLM response, diff, secret scanning, and verification parsing
• reorganize Config into flattened Vault, GitHub, Agent, and Verification domain structs while migrating a slice of the command tree to idiomatic mod.rs modules
• align release metadata with 0.5.26, add a release workflow guard for tag/version drift, and pin the Rust toolchain so the current dependency graph is reproducible
• merge the latest main changes, resolve conflicts in the eval/config/verification pipeline, and preserve the diff parser fix for zero-count hunks

Testing

• cargo test

Slack Thread

  

[haasonsaas]

@cursor review and resolve merge conflicts

[cursor]

Skipping Bugbot: Bugbot is disabled for this repository. Visit the Bugbot dashboard to update your settings.

[haasonsaas]

@cursor review and resolve merge conflicts

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Filter in parse_optional_capture rejects valid zero line counts
  • Removed the zero-value filter so hunk headers preserve valid 0 line counts, and added regression assertions for new and deleted file hunks.

[sentry]

Bug: The parse_optional_capture function incorrectly converts 0 to 1 for line counts in diff hunk headers, breaking parsing for new files, deleted files, and pure insertion/deletion hunks.
_{Severity: CRITICAL}

Suggested Fix

Remove the .filter(|value| *value > 0) call within the parse_optional_capture function. This will allow the parser to correctly handle 0 as a valid line count in diff hunk headers, which is necessary for new files, deleted files, and pure insertion/deletion hunks.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/core/diff_parser.rs#L478

Potential issue: In `diff_parser.rs`, the `parse_optional_capture` function uses
`.filter(|value| *value > 0)` followed by `.unwrap_or(1)`. This incorrectly converts a
line count of `0` in a diff hunk header to `1`. This affects hunks for new files,
deleted files, and pure insertions/deletions. The hunk termination logic `consumed_old
>= old_lines && consumed_new >= new_lines` then fails because one of the conditions
(e.g., `consumed_old >= 1` for a new file) can never be met. This causes the parser to
read past the end of the hunk, corrupting the parsed diff output.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[haasonsaas]

@cursor resolve the merge conflictss and address all feedback

[cursor]

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Filter in parse_optional_capture rejects valid zero line counts
  • Removed the zero-value filter so hunk headers preserve valid 0 line counts, and added regression assertions for new and deleted file hunks.