Refuse signing without keypair instead of returning zeroes

[ilchu]

The provider node had two duplicated fallbacks that silently returned a 64-zero-byte placeholder when no signing keypair was configured: one in ProviderState::sign (lib.rs:131-134) and one in the /checkpoint/sign handler (api.rs:604-608). Any provider booted without --keyfile would emit cryptographically invalid signatures into the commitment / checkpoint flow, and callers had no way to tell a real signature from a placeholder.

Change ProviderState::sign to return Result<String, Error> and yield Err(Error::SigningUnavailable) when no keypair is configured. Add a new Error::SigningUnavailable variant that maps to HTTP 503 Service Unavailable with error: "signing_unavailable". All five state.sign(...) call sites in api.rs propagate via ?; the duplicate match in sign_checkpoint_proposal_handler was removed and now goes through the same state.sign(&encoded)? path as every other handler.

Tests:

• New unit tests in provider-node/src/lib.rs verify that sign() refuses without a keypair, that the produced signature is real sr25519 that verifies under //Alice's public key, that schnorrkel randomisation gives distinct-but-valid signatures across calls, and that //Bob's signature does not verify under //Alice (negative control).
• New integration tests in provider-node/tests/api_integration.rs reconstruct the CommitmentPayload the handler signs and verify the returned signature with sr25519::Pair::verify, plus dedicated tests proving each previously zero-byte-emitting endpoint (/commit, /commitment, /checkpoint/sign, /delete) now returns 503 with the right error code when no keypair is configured.
• TestServer::new() and start_test_provider now use with_seed("//Alice") so existing signing-bound tests still exercise end-to-end.