InMemoryCredentialStore::supportsDurableRevocation() reports true even though it is process-local #49

src/Runtime/Credentials/InMemoryCredentialStore.php:48 returns true from supportsDurableRevocation(), but the store keeps everything in a private $byJob array that disappears when the PHP process exits. src/Runtime/ARCPRuntime.php:107 uses that signal as the only precondition for accepting a configured CredentialProvisioner: if it returns true, the runtime allows provisioned credentials; if it returns false, the runtime refuses construction with "provisioned credentials require a durable revocation store." Lying here lets a host wire InMemoryCredentialStore into a provisioned-credential configuration and silently lose the ability to revoke leaked credentials after a restart.

This contradicts the docblock at src/Runtime/Credentials/CredentialStore.php:25, which presents supportsDurableRevocation() as a capability flag the runtime relies on for safety, and it weakens the gate that distinguishes the in-memory test double from a real persistent store.

Fix prompt: Change InMemoryCredentialStore::supportsDurableRevocation() to return false, since its state evaporates on process exit. Update the unit test in tests/Unit/Runtime/Credentials/InMemoryCredentialStoreTest.php to assert the new value, add a runtime configuration test that constructs ARCPRuntime with a CredentialProvisioner plus InMemoryCredentialStore and asserts the constructor throws the documented InvalidArgumentException, and add a note in docs/guides/leases.md or a new credentials guide explaining which store implementations are durable.