Add E2E coverage for default signed-header compatibility with KERIA main

[kentbull]

Goal

Prove that the unchanged/default SignifyPy signed-header client remains compatible with KERIA main after WebOfTrust/keria#351 adds ESSR support.

This test belongs in SignifyPy because the compatibility obligation is that the client keeps working without selecting or implementing ESSR.

Implementation

Add a focused test to the existing live integration suite that:

• Uses the existing client_factory and real multi-process KERIA stack.
• Constructs and connects SignifyPy normally, without an ESSR mode or authentication override.
• Exercises an authenticated GET /identifiers.
• Exercises a state-changing POST /identifiers by creating a witnessless single-signature identifier.
• Preserves the normal SignifyPy response-verification hook.
• Captures the resulting prepared requests and responses.
• Asserts requests use their ordinary endpoint paths rather than the ESSR POST / wrapper.
• Asserts request and response signed-header fields remain present.
• Asserts the identifier is created and readable.

After WebOfTrust/keria#351 merges, advance the SignifyPy integration KERIA pin to the resulting commit on KERIA main and run this test against that source.

Acceptance criteria

• The focused compatibility test passes against the post-merge KERIA main commit.
• Existing SignifyPy live integration tests remain green against the same KERIA commit.
• The test runs in the existing SignifyPy live-integration CI job.

Out of scope

• Controller/passcode rotation, tracked by Provide support for passcode rotation keria#222.
• Adding ESSR support to SignifyPy.
• Making ESSR the default authentication mode.