flagon-io/g1t

Closes #365. Closes #368. Two fixes, one deploy.

#365: a branch made from a merged pull request

• What happened: #362's branch was made from #360's branch, and #360 then merged with a merge commit. After that:
  • g1t's test merge saw conflicts that git doesn't have.
  • update_branch answered needs_agent/conflicting.
  • No CI / pull_request run was ever created, so the required check waited forever.
• Cause (services/repos): g1t searched for the merge base only along main's first-parent line (GitRepo::log lists first parents). #360's head reached main only as the second parent of its merge, so the search went past it to where #360 had first left main.
• Fix:
  • services/repos/src/merge_base.rs finds the merge base the way git merge-base does, over the whole graph:
    • It walks the head over all parents down to main's line.
    • It walks the other parents of main's merges above that point, with bounded reads (16 commits each, 8 at a time, 128 in all, and none when there are no such merges).
    • It keeps the shared commits nothing else shared descends from.
    • Rebase and squash use what it finds so they don't replay commits main already has through a merge.
  • Every caller now uses it: the test merge, update_branch, mergeability, merge and rebase landing, the compare view, and rule inspection.
  • CI starts regardless (services/actions/src/trigger.rs): when only g1t's own test merge saw a conflict and the PR doesn't show itself as conflicting, CI now builds the head instead of running nothing. A PR that really conflicts still runs nothing, and shows why.
• pulls.merge_base being null on an open PR is normal: it's written when a PR merges.

#368: a log report re-read the whole log

• Migration 0027_log_bytes.sql adds jobs.log_bytes, a running count, filled in for unfinished jobs.
• Each log report checks the 4 MB cap against that count and sends one D1 batch: add to the count and seen_at, then insert. That's 2 database calls instead of 4, and no SUM(LENGTH(text)) over the whole log.
• Resends: a resent chunk is neither stored nor counted twice.
• The cap behaves as before: each report is trimmed to 256 KB, the report that reaches 4 MB is kept with the "limit of 4 MB" line, and later reports are dropped.
• A re-run resets the count, and g1t's own note lines are counted too.
• What's different:
  • The cap is now counted in bytes, not characters.
  • Jobs that were already running during the deploy may undercount by a few chunks.

Checks

• cargo test -p g1t-repos (419), -p g1t-actions-service (139), and -p g1t-work (343)
• New tests:
  • The stacked-branch merge base (7 cases).
  • A test merge and a catch-up/rebase of the #362 shape.
  • The trigger building the head.
  • The log byte count, resend handling, the cap, and the backfill.
• merge_base.rs is rustfmt-clean, and the other changed files have no new drift.