fix(smithy): sf task merge honors workspace merge.targetBranch config (#63)

[komoreka]

Summary

Closes #63.

merge.targetBranch in .stoneforge/config.yaml was previously consumed only by prompt-builders (sessions, steward scheduler, dispatch daemon) which feed it into WorkflowPresetContext for agent system prompts. The actual git tooling in sf task CLI commands and the MR-creation path never loaded it. So setting merge.target_branch: dev told agents about the target in their prompts, but sf task merge, sf task complete, sf task sync, and sf task update --status merged all still defaulted to git origin/HEAD (typically main) when no per-task targetBranch was set.

This PR wires the config value into all merge-related code paths. Resolution chain across the affected commands is now:

task.targetBranch → config.merge.targetBranch → git origin/HEAD → main

This unblocks the steward case from #63: stewards cannot own a targetBranch field per the agent-type contract (the API rejects PATCH attempts), so a workspace-level config has always been the only path available to them. Now it actually flows through to git.

What changed

• packages/smithy/src/cli/commands/task.ts — exports loadConfigTargetBranch() helper; threads it into the mergeTaskHandler (mergeBranch call + post-merge verify), the sync handler, and the update --status merged verify path.
• packages/smithy/src/services/task-assignment-service.ts — same fallback in the MR-creation path used by sf task complete.
• packages/smithy/src/cli/commands/task-target-branch.bun.test.ts (new) — 6 unit tests for the helper covering: value present, missing config file, missing merge block, null value, empty string, slash-bearing branch names.

Test plan

• bun test src/cli/commands/task-target-branch.bun.test.ts — 6/6 pass
• bun test src (full smithy suite) — 1574 pass, 0 fail, 19 skip
• Full workspace pre-PR validation:
  • turbo run typecheck — 16/16 pass
  • pnpm build — 13/13 pass
  • bun test on core (2737/0/22), storage (137/0/0), quarry (4260/0/1), smithy (1574/0/19) — total 8708 passing, 0 failing
• Live probe against a real workspace's .stoneforge/config.yaml — confirmed the helper resolves null, plain values (dev), and slash-bearing values (release/v2) correctly when called from inside the workspace.

Out of scope (deferred)

• The deeper director→task propagation discussed in bug: sf task merge defaults to 'main' for stewards — targetBranch is director-only, no fallback #63's review — currently dispatch-daemon.ts:2890-2896 propagates the director's targetBranch onto a task only during assignTaskToWorker, which means tasks not yet worker-dispatched (or where resolveOwningDirector fails) never get it. Worth a follow-up issue/PR if desired; happy to file separately. This PR closes the user-visible symptom by making the config workaround actually work end-to-end.