Fix GPT-5.x reasoning-item orphaning in history compaction + persist foundry resource name

[breedx]

Summary

Two related fixes for GPT-5.x reasoning models on the OpenAI Responses API and Azure AI Foundry, both surfaced while using foundry-gpt-5.5.

1. fix(compaction): preserve ThinkingParts carrying encrypted reasoning state

This is the important one — it affects any GPT-5 / o-series model on the Responses API (OpenAI, Azure Foundry OpenAI, ChatGPT OAuth), not just Foundry.

On the OpenAI Responses API, reasoning items arrive as ThinkingPart(content='', signature='<encrypted>', id='rs_...') — empty text, but the signature carries the encrypted reasoning state that must round-trip back so the paired msg_... item in the next turn is not orphaned.

_strip_empty_thinking_parts in code_puppy/agents/_compaction.py was dropping any ThinkingPart with empty content, including those carrying encrypted reasoning. On the next turn the API rejected with:

'msg_...' of type 'message' was provided without its required 'reasoning' item: 'rs_...'

Now we only strip when content is empty and there is no signature, id, or provider_details — anything carrying provider state survives compaction.

2. feat(azure_foundry): persist resource name across sessions

/foundry-setup re-prompted for the resource name every run unless the user exported ANTHROPIC_FOUNDRY_RESOURCE. The wizard now saves the chosen name to puppy.cfg under azure_foundry_resource, so the next run pre-populates it.

Resolution order is preserved for env-var users:
ANTHROPIC_FOUNDRY_RESOURCE (env) → puppy.cfg → None

(Happy to split this into a separate PR if you'd prefer to land #1 on its own.)

Test plan

• uv run pytest tests/agents/test_compaction.py — all pass (includes new test_preserves_empty_thinking_with_signature)
• uv run pytest tests/plugins/test_azure_foundry.py — all pass (includes new tests for cfg fallback, env precedence, and persistence)
• uv run ruff format --check — clean
• uv run ruff check — clean
• Manual smoke test with foundry-gpt-5.5 — the original msg_.../rs_... error no longer fires on multi-turn conversations

[breedx]