fix(pi): pass configured model to launch commands

[Hardik180704]

Closes #2892

Pi was ignoring the role-specific model configured in AO and using its default model instead.

This PR:

• adds the model field to Pi's config spec
• forwards the configured model during launch and restore
• trims model values and skips blank ones
• keeps --model before Pi's positional prompt and --session
• adds regression tests for the config, launch, blank-model, and restore cases

Tests:

• npm run lint
• go test -race ./...
• go build ./...
• go vet ./...
• frontend typecheck and e2e typecheck
• frontend Vitest: 896 passed
• renderer smoke: 20 passed

@Pulkit7070 @nikhilachale could you please review this when you get a chance?

[codebanditssss]

This is the strongest of the four model-forwarding PRs I've read in this series, and the tests are the reason.

I mutation-tested the ordering guarantee rather than trusting the assertion, since it's the part that actually matters here — Pi's own doc comment notes it doesn't honour a -- options terminator, so --model genuinely has to precede the trailing positional prompt. Moving appendModelFlag after the prompt append:

--- FAIL: TestGetLaunchCommandAppendsConfiguredModelBeforePrompt
    cmd = []string{"pi", "--append-system-prompt", "follow repo rules",
                   "add a health check", "--model", "openai/gpt-4o"},
    want []string{"pi", "--append-system-prompt", "follow repo rules",
                  "--model", "openai/gpt-4o", "add a health check"}

Caught, and the test name encodes the constraint so the next reader knows it's deliberate rather than incidental. All tests pass unmutated; all 9 checks green.

Four things this does better than its siblings, worth naming since they're cheap to copy:

• reflect.DeepEqual on the complete argv for launch and restore, so ordering is pinned on both paths rather than just presence
• whitespace trimming folded into the ordering test (" openai/gpt-4o "), so one assertion covers two properties
• blank-model case uses " \t " rather than plain spaces
• TestGetConfigSpecReportsModelField deep-equals the whole field slice including Description, which is stricter than kimi's key/type check and considerably stricter than copilot's

Approving. One series-level note inline — not a defect in this PR, but something the four of you probably want to settle once rather than per-adapter.

[codebanditssss]

That's exactly what was needed — thank you for actually running it rather than reasoning about it. As far as I can tell this is the first empirical data point in the whole model-config series; #2975, #2985 and this PR were all resting on the same absence of evidence.

Approval stands, now on verified rather than inferred grounds.

One scoping note so nobody over-extends it: this settles Pi. It doesn't automatically carry to Kimi, even though both use --session — different CLIs, same flag name is a coincidence rather than a shared contract. And Copilot uses --resume, so it's untouched by this.

I'll point #2985 and #2975 at your result so the series has something concrete to reason from.