Consider incremental storage for Responses history

[leseb]

Parent: #93

Praxis currently persists expanded response history for rehydration. That is simple, but over a long previous_response_id chain it can duplicate prior turns into many response records and trend toward O(n^2) storage across the chain.

Scope:

• Evaluate an incremental storage model for Responses history: parent response link plus current request input/output only.
• Reconstruct full history on GET/rehydrate when needed.
• Add cycle detection if not already implicit in storage relationships.
• Add max_chain_depth and max_rehydrated_bytes checks during reconstruction.
• Preserve existing API behavior for stored Responses records.
• Compare migration complexity against the simpler capped-expanded-history approach.

Notes:

• Incremental storage reduces DB duplication, but it does not remove the need for a hard rehydration cap; the proxy can still materialize a very large chain before the backend sees it.
• This should follow the defensive-cap work rather than block it.