Add deterministic local Git workflow effects

[taras]

Story

As a workflow author, I want deterministic local Git components to switch branches, stage selected changes, and commit staged content inside a retained Repository or Worktree.

Current delivery state

Git.Switch and Git.Add are shipped. PR #474 delivered branch switching, PR #477 delivered explicit staging, and PR #481 bound the branch transition to the request that admitted it. Git.Commit is the remaining delivery slice; this issue closes when that component and its interruption/reconciliation contract ship.

Contract

The provider-neutral component set is:

• Git.Switch for changing or creating the current branch;
• Git.Add for staging explicit paths; and
• Git.Commit for committing exactly the current index.

Git.Checkout may be supplied as a compatible Git-shaped operation where its semantics are explicit, but Git.Switch is the primary branch operation. Git.Commit accepts message as a prop and children as an expandable message; retaining both supports convenient bindings and pre-commit expansion.

Each component is one expansion, one effect, and one Workspace transaction. A commit does not bundle arbitrary child mutations into its transaction: children finish first, then the commit expansion commits the staged index.

Agents remain read-only. They do not supply a privileged authorized-path set; changes reach Git through ordinary durable File and Git.Add effects.

Acceptance

• Every operation uses the contextual Repository or Worktree and has no path prop.
• Git.Switch changes the named branch deterministically and rejects incompatible retained state.
• Git.Add stages only its explicit path inputs and reports the resulting index/tree identity.
• Git.Commit commits only staged content and fails clearly when nothing is staged.
• Child content and a message prop both produce the intended commit message with documented precedence or conflict behavior.
• Replay cannot create a duplicate branch transition, staging result, or commit.
• Interruption after commit creation reconciles the existing commit under the same effect identity.
• Results identify branch, commit, parent, and tree.
• Local Git metadata and the filtered result commit through Commit Workspace mutations and journal results atomically #365's transaction boundary.

Dependencies

• Add named Repository and Worktree composition #293 supplies Repository and Worktree context.
• Commit Workspace mutations and journal results atomically #365 supplies atomic Workspace-local effects.
• PR 📝 Specify retained workflow Workspaces #358 supplies the public Git composition contract.
• End goal: ✨ Compose and certify the supervised adversarial implementation workflow #181.

[taras]

Architecture note from #181 reorientation: local Git effects and journaling

Git.Switch, Git.Add and Git.Commit should operate through contextual Git APIs, not direct CLI assumptions in shared modules. The initial Deno provider can use native Git; browser or future hosts can implement the same contract differently.

Git.Commit is a Workspace-local durable effect when the Repository/Worktree lives inside the retained Workspace. It should participate in the #365 transaction boundary for local mutation plus journal result. The journal should retain reconciliation evidence, not raw Git object contents: repository/worktree identity, branch, commit SHA, parent SHAs, tree SHA, staged paths and message evidence.

Replay of a completed Git.Commit must not create another commit. Resume after uncertain local completion reconciles against retained Workspace Git state: a matching commit/tree/parent/message is accepted; missing retained state is corruption; incompatible branch or commit state fails without implicit reset, rebase or merge.

This preserves one expansion -> one effect -> one Workspace transaction while avoiding a journal that tries to encode the Git object database.