Codeg task branches use internal task IDs instead of linked issue numbers

[Luis-WowApps]

When I start a Codeg task from GitHub issue #152, CodeG creates a git worktree/branch named from the internal CodeG task ID:

C:\_Data\Projects\WowApps-task-2
branch: task/2

title: #152 · AI Calls: Reconcile page & offboarding
source_key: github:github.com:wowappsdev/wowapps-core:issue:152
work_branch: task/2

This is confusing because the real issue branch expected by our workflow is 152-ai-calls-reconcile, while CodeG leaves an extra empty branch/worktree task/2. Orca then shows both branches, but Orca is correct because both are real git worktrees.

Expected behavior:
For a task linked to a GitHub issue, CodeG should name the work branch/worktree from the linked issue number/title, or at least make it clear that task/2 is CodeG’s internal task branch.

Actual behavior:
CodeG creates task/<internal_task_id> and <repo>-task-<internal_task_id>, even when source_meta.number is available.

Evidence from current CodeG source:
src-tauri/src/work_task/engine.rs creates:

let branch = format!("task/{}", task.id);
let dir = format!("{}-task-{}", basename(&root.path), task.id);

This caused:

• work_task.id = 2
• GitHub issue = #152
• created branch = task/2
• created worktree = WowApps-task-2
• files changed = 0 because it was a report/plan task

Impact:
Users see an empty task/2 branch/worktree plus their real issue branch, and it looks like Orca/CodeG duplicated or lost the work.

[dawNotPoi]

I’d like to work on this. I’ll reproduce the current GitHub-issue task path on the latest main, then add source-aware worktree/branch naming while preserving unique, valid Git refs and the existing behavior for non-GitHub tasks. I’ll cover creation and recovery/retry behavior with focused tests.