Recipe-backed sessions should remain loadable when recipe metadata is incomplete or invalid

## Summary

A session with an attached recipe can fail to load in ACP if the stored recipe is now considered invalid. The session transcript itself is still valid, so the session should remain visible/loadable even if recipe hydration fails.

Observed while testing ACP remote server TLS: loading session `20260626_83` failed with:

```text
recipe: Invalid recipe:
Unnecessary parameter definitions: pr.
```

That error is unrelated to TLS, but it exposed a broader recipe/session persistence issue.

## Problems

1. **ACP `loadSession` fails hard when applying the stored recipe fails.**
`handle_load_session` calls `apply_session_recipe` and returns the error, which prevents the whole session from loading.

Relevant path:
- `crates/goose/src/acp/server/load_session.rs`
- `crates/goose/src/acp/server/recipe/mod.rs`

2. **CLI recipe runs do not persist the same recipe metadata as ACP-created recipe sessions.**
ACP new-session stores the recipe plus `user_recipe_values`. CLI recipe runs store the recipe, but not the parameter values/block needed to faithfully reload the recipe-backed session later.

Relevant paths:
- `crates/goose/src/acp/server/new_session.rs`
- `crates/goose-cli/src/session/builder.rs`

3. **CLI recipe runs should likely be implicitly trusted.**
If a user explicitly ran a local recipe from the command line, the resulting session should not later be treated like an untrusted/imported recipe in Desktop/ACP flows.

4. **The original recipe base directory is not preserved for reload.**
ACP re-renders stored session recipes using the global recipe library dir. That can break recipes that depend on `recipe_dir`, file parameters, or relative sub-recipes if the original recipe came from somewhere else.

## Expected behavior

- Loading a historical session should be best-effort with respect to recipe metadata.
- If recipe hydration/rendering/application fails, the transcript should still load.
- The server should log the recipe hydration failure and surface enough metadata for the UI to show a warning if needed.
- CLI recipe sessions and ACP recipe sessions should persist enough metadata to reload consistently: original recipe, user parameter values, base/source directory, and trust state.

## Notes

This may need a small session metadata cleanup rather than a point fix. Recipe validation rules can change over time, so old sessions should remain readable even when their saved recipe no longer passes current validation.

Start by examining the session loading flow in `crates/goose/src/acp/server/load_session.rs` and `crates/goose/src/acp/server/recipe/mod.rs`. Compare how recipe metadata is persisted in `crates/goose/src/acp/server/new_session.rs` versus `crates/goose-cli/src/session/builder.rs`. The goal is to make session loading resilient to recipe hydration failures, ensuring the transcript loads even if the recipe is invalid. Look for where errors are returned and consider logging instead of failing.

Escrito por el modelo de indexación a partir del texto del issue.