fix(delegation): keep a child's working directory out of the sidebar

A delegated sub-task resolved its child conversation's `folder_id` through
`add_folder`, which unconditionally sets `is_open = true`. Whatever directory the
agent chose as `working_dir` — a pull request checked out under /tmp, a throwaway
worktree — therefore became a top-level project in the sidebar, standing beside
real repositories with no `parent_id` to nest it under one. Delegating into a
folder the user had closed reopened it, and every delegation bumped
`last_opened_at`, reordering the folder history behind them.

That row was never read to render anything. Delegation children are not sidebar
rows — the conversation list selects roots only (`parent_id IS NULL`) and
children render lazily beneath their parent — so the row exists to carry the
child's `folder_id` and to supply the resumed connection's working directory.
Both of those go through lookups that filter on `deleted_at` alone and never
consult `is_open`.

The delegation host now takes its folder through `ensure_folder_for_path`, which
registers the directory without opening it into the workspace. A live row comes
back untouched, keeping `is_open`, `last_opened_at`, `parent_id`, `name` and
`group_id` as they were; a new row starts closed, and still takes a `sort_order`
so that opening it later, deliberately, lands it in a sane position.

A soft-deleted row is revived, since both cwd lookups filter it out and a deleted
row would fail the very resume it is being created for — but revived closed.
`remove_folder` stamps only `deleted_at` and leaves `is_open` at whatever it
held, so a deleted row's flag says nothing; honoring it would put a folder the
user had removed back in their sidebar.