resolve-merge-conflictslisted

# Resolve Merge Conflicts Resolve git conflicts that arise from a `merge` or `rebase`, then verify the working tree builds cleanly before completing the operation. The goal is not to mechanically pick one side. A conflict means two changes touched the same lines, and the correct result is usually a *combination* that preserves the intent of both. Read each side, understand *why* it changed, and integrate accordingly. If `$ARGUMENTS` names a branch, treat it as the branch to merge (or rebase onto) when starting a fresh operation. ## Step 1: Detect the current state Run `git status` and inspect the repository to figure out which situation you are in: - **Already mid-conflict** — `git status` shows "Unmerged paths" and the repo is in a `MERGE`, `REBASE`, or `CHERRY-PICK` state. Skip to Step 3. - **Clean, conflict not started yet** — the user wants you to start a merge/rebase against a branch. Continue to Step 2. To distinguish a merge from a rebase when already mid-conflict, check for state directories: `.git/MERGE_HEAD` indicates a merge in progress; `.git/rebase-merge/` or `.git/rebase-apply/` indicates a rebase. This matters because the completion and ours/theirs semantics differ (see Step 5 and the marker reference below). ## Step 2: Start the operation (only if not already mid-conflict) 1. Confirm the working tree is clean with `git status --short`. If there are uncommitted changes, stop and ask the user how to proceed (commit, stash, or abort) — never discard thei