辅助任务现在可以正确解析命名自定义 provider（custom:name）。

Before this fix, _normalize_aux_provider() would strip the "custom:" prefix
and return bare "custom", which routes through the anonymous-custom path
(reading model.base_url + OPENAI_API_KEY from config/env).  Users with
named custom_providers (e.g. custom:qwen) but no OPENAI_API_KEY set would
silently get "Goal judge is not configured" or broken vision tasks.

Two changes:
1. Remove the early return in _normalize_aux_provider() that stripped
   custom:xxx → custom.  Named custom providers are now preserved intact
   so resolve_provider_client can route them through the named-custom-provider
   branch which reads custom_providers from config.yaml.
2. Add a fallback in _resolve_custom_runtime(): when requested="custom"
   falls back to OpenRouter (because no bare "custom" entry exists), try
   resolve_runtime_provider(requested=None) to pick up the user's actual
   main provider.  This is a safety net for code paths that still call
   with bare "custom".

Affected tasks: vision, goal_judge, compression, web_extract, etc.
Any auxiliary task that uses "custom:name" as provider now works.

修复前：_normalize_aux_provider() 会把 custom:qwen 强制 strip 成 "custom"，
导致所有带命名自定义 provider 的辅助任务（vision、goal_judge 等）都走匿名
custom 路径（读环境变量 OPENAI_BASE_URL/API_KEY）。用户如果没有设置这些
环境变量，辅助任务就静默失败。

修复后：
1. 移除 strip 逻辑，保留 custom:name 完整字符串，让 resolve_provider_client
   走 named custom provider 分支，从 custom_providers 读取 base_url + api_key。
2. 在 _resolve_custom_runtime() 增加 fallback：当 "custom" 回退到 OpenRouter
   时，尝试用 requested=None 重新解析用户实际的主 provider 作为兜底。

影响范围：vision（图像识别）、goal_judge、compression、web_extract 等
所有使用 custom:name 作为 provider 的辅助任务现在都正常工作。

Fixes: custom provider vision tasks broken, goal judge unavailable
Related: NousResearch#37182

…ace (NousResearch#37182)

When a dispatcher-spawned worker (HERMES_KANBAN_TASK set) calls
kanban_create without an explicit workspace, the new child now inherits
the worker's own running-task workspace_kind/workspace_path instead of
defaulting to scratch. A worker editing a dir:/worktree project that
spawns a follow-up child keeps it in that project.

Orchestrators (kanban toolset, no HERMES_KANBAN_TASK) and CLI/dashboard
callers still default to scratch. An explicit workspace arg always wins.