fix(claude): isolate generated settings by profile identity

[drewstone]

A recursive Claude child with different tool permissions failed before inference because its generated settings collided with its parent's settings in their shared task directory.

Place generated Claude settings at a path containing the exact profile digest and point --settings there.
The existing materializer still validates and applies the plan, and its receipt records the actual path.
Retained sessions keep their already-applied plan so upgrading the bridge does not change their materialization identity.

The task directory, OAuth behavior, and native skill names are unchanged.
Shared skills and task files still require identical bytes; conflicting skill content remains refused.

Validation covers the reproduced settings conflict, old-root/new-child coexistence, stable resume, conflicting skill refusal, and real subprocess launches through ClaudeBackend reading distinct settings in the same directory.
Typecheck and the Linux suite pass: 1,032 tests passed and 21 explicitly skipped, plus the published Runtime consumer test.
No live model run or bridge restart is included.

[drewstone]

Integration review: the measured Discovery child failure came from a second generated Claude settings file targeting the root settings path. This patch keeps the shared cwd and authored task/skill bytes, changes only the generated settings path and explicit --settings argument, and keeps retained-session plan identity stable. I reviewed the source and coexistence/conflict/resume/subprocess tests. Linux CI is green. The subprocess test is not a live Claude capability-denial proof; differing same-name skill bytes and native tool-policy exactness remain separate limitations. Live deployment is still pending.