berdctl session create should inherit the spawning session’s project

### Before filing

- [x] I searched [open and closed issues](https://github.com/block/berd/issues?q=is%3Aissue) for duplicates.
- [x] I reproduced this on the [latest release](https://github.com/block/berd/releases).
- [x] This is one bug, not several bundled together.

### Closest existing issue

221

### What's broken

When a chat that belongs to a Berd project spawns a new chat through
`berdctl session create`, the child does not reliably inherit the spawning
chat’s project.

If `--project-id` is omitted(optional parameter), the child can be filed under the active app
project instead of the parent chat’s project. This is easy to miss when the
app is currently viewing a different project.

That breaks project-scoped coordination. A parent and its worker can appear in
different project views even though the worker was created specifically for
that parent’s work.

### Steps to reproduce

1. Open or run a chat that belongs to Project A.
2. Change the active Berd app project to Project B, or otherwise make another
project active.
3. From the Project A chat, run `berdctl session create` without
`--project-id`.
4. Observe that the created child is not reliably assigned to Project A.

### What you expected to happen

When `berdctl session create` runs from a Berd chat, the default project should
be the spawning chat’s `project_id`.

Explicit `--project-id` should continue to override that default.

### What actually happened

It inherets the currently selected project in Berd UI (not the project of the session it was created from)

### How often does it happen?

Every time — reliably reproducible

### Berd version

0.5.19

### Operating system

macOS (Apple Silicon)

### Model and provider

GPT 5.6 Terra

### Relevant log output

```text
Environment:
- Berd 0.5.19
- macOS (Apple Silicon)
- Updated through the Berd UI on 2026-08-28

Reproduction command:

berdctl session create \
--prompt '[Berd project inheritance reproduction test] This is a no-work test session. Reply only: Test complete.' \
--harness-id goose \
--json \
--timeout-ms 30000

Result:

{"harness_id":"goose","send_status":"dispatched","session_id":"20260828_17","title":"New chat"}

Created-session metadata:

{
"session_id": "20260828_17",
"project_id": null,
"is_running": true,
"chat_state": "streaming",
"title": "New chat",
"updated_at": "2026-08-28T12:59:51+00:00"
}

The initiating Berd session belonged to project_id "my-berd-project".
The new session was created without --project-id and received project_id null.

Relevant sanitized Berd app-log lines:

[2026-08-28][12:59:48][tauri_plugin_berdctl::server][INFO] [berdctl] /v1/call command=info result=ok duration_ms=114
[2026-08-28][12:59:51][berd_lib::commands::renderer][INFO] [renderer] [reasoning-effort] acpCreateSession newSession response {"sessionId":"20260828","providerId":"databricks_v2","requestedModelId":"goose-gpt-5-5","providerSetupDeferred":false,"hasReasoningEffortSnapshot":true}
[2026-08-28][12:59:51][berd_lib::commands::renderer][INFO] [renderer] [reasoning-effort] createSession acp resolved {"sessionId":"20260828","providerId":"goose","modelId":null,"hasReasoningEffort":true}
[2026-08-28][12:59:51][berd_lib::commands::renderer][INFO] [renderer] [reasoning-effort] createSession inserted {"sessionId":"20260828","providerId":"goose","modelId":null,"hasReasoningEffort":true}
[2026-08-28][12:59:51][tauri_plugin_berdctl::server][INFO] [berdctl] /v1/call command=sessions result=ok duration_ms=3293
[2026-08-28][12:59:55][tauri_plugin_berdctl::server][INFO] [berdctl] /v1/call command=sessions result=ok duration_ms=237

No error was emitted in berd.log during this reproduction. The unexpected behavior is the created session's project_id being null rather than inheriting the initiating session's project.
```

### Screenshots, recordings, or other context

_No response_

Trace `berdctl session create` through the `tauri_plugin_berdctl` server, especially `/v1/call` with `command=sessions`, and the renderer `createSession` path shown in the logs. Verify how the spawning session and optional `--project-id` are handled. Done means an omitted project ID inherits the parent chat's project while an explicit ID still overrides it.

Written by the indexing model from the issue text.