ravencoin: expose Core backend capability

[ALENOC]

Summary

This adds an optional, Ravencoin-only server.ravencoin_backend RPC so Ravencoin Electrum clients can determine which Ravencoin Core daemon is actually behind an ElectrumX server.

The change is intentionally isolated and does not require a separate ElectrumX installation or process. It is designed for the existing multi-coin deployment model.

The implementation was prepared against cipig/electrumx master commit c9dc2e138888da08843414b2072c40901f20032d.

Why

After the recent Ravencoin consensus incident, an Electrum client should not infer backend safety merely from the fact that an ElectrumX server is reachable.

A client needs a way to inspect sanitized evidence about the configured ravend, including the Core version. In particular, Ravencoin Core encodes 4.8.0 as numeric version 4080000, which needs Ravencoin-specific parsing rather than the generic Bitcoin version-number interpretation.

This RPC is the interoperability capability used by Electrum-Ravencoin. The server reports evidence; the client remains responsible for applying its own trust/safety policy.

What changes

For COIN=Ravencoin only, the environment installs small Ravencoin-specific subclasses:

• RavencoinDaemon, extending the existing daemon adapter;
• RavencoinElectrumX, extending the existing session class;
• Ravencoin incident-era header checks.

server.ravencoin_backend reports only sanitized public information:

• Core version string and numeric version;
• Core subversion;
• network;
• block/header heights;
• initial-block-download state;
• synchronization state;
• incident checkpoint result;
• KAWPOW nHeight validation capability;
• optional operator-configured Core build identity.

The daemon information is cached briefly to avoid creating unnecessary load on ravend.

Backward compatibility

Backward compatibility with existing and older Electrum clients is a hard requirement of this change.

This PR does not:

• raise PROTOCOL_MIN;
• change server.version;
• remove or alter an existing RPC;
• change protocol negotiation;
• require clients to understand the new method;
• change the generic daemon/session path for other coins.

RavencoinElectrumX.set_request_handlers() first calls the existing ElectrumX.set_request_handlers(ptuple) and only then adds server.ravencoin_backend.

Therefore an older client continues to use exactly the handlers selected by the existing Electrum protocol version negotiation. A client that does not know server.ravencoin_backend simply never calls it.

The tests explicitly exercise representative protocol tuples (1, 0), (1, 4, 2), (1, 6) and (1, 7) and verify that inherited handlers are preserved.

Other coins are unaffected

The extension is activated only when the selected coin class has NAME == "Ravencoin".

BTC, LTC, ZEC and the other coins served by the same ElectrumX codebase continue to use their existing DAEMON, SESSIONCLS, protocol handlers and configuration unchanged.

This is important for the multi-coin architecture: no second ElectrumX install is required.

Requested deployment on all three Cipig RVN servers

Merging the code is only the first part of this request. Please also deploy the updated ElectrumX code to all three public Cipig Ravencoin endpoints:

• electrum1.cipig.net — SSL 20051, TCP 10051
• electrum2.cipig.net — SSL 20051, TCP 10051
• electrum3.cipig.net — SSL 20051, TCP 10051

The goal is for server.ravencoin_backend to be available and return truthful live evidence from the ravend actually used by each of the three servers.

After deployment, each endpoint should be independently checked. The feature should not be considered operational until all three servers answer server.ravencoin_backend successfully and report their real Ravencoin Core backend.

This matters because these three endpoints are already present in Electrum-Ravencoin discovery as discovery-only servers. They can only become independently verifiable by the hardened client once the capability is live on the actual public servers.

If the three servers share the same ElectrumX installation/code tree, a single code update is of course fine; the important requirement is that the updated service is restarted/reloaded for all three RVN endpoints and that the RPC is live on each of them.

Ravencoin safety evidence

The implementation includes the Ravencoin-specific evidence expected by current Electrum-Ravencoin clients:

• minimum patched Core version: 4.8.0;
• incident checkpoint height 4,487,775;
• incident checkpoint hash verification;
• KAWPOW header nHeight validation from height 4,487,776;
• network and synchronization evidence.

These are evidence fields, not a replacement for client-side validation.

Core build identity

Core identity is deliberately not hard-coded.

The operator can configure:

• RAVENCOIN_SOURCE_REPOSITORY
• RAVENCOIN_SOURCE_TAG
• RAVENCOIN_SOURCE_COMMIT
• RAVENCOIN_ARTIFACT_SHA256
• RAVENCOIN_IDENTITY_EVIDENCE

This prevents the server from claiming to run a certified build unless that is actually how the deployment was built/configured.

If only the daemon's version is known, the response truthfully falls back to VERSION_ONLY evidence. A client can then decide whether that is sufficient under its own policy.

Tests

The added tests cover:

• Ravencoin numeric version parsing (4080000 -> 4.8.0);
• backend response schema;
• pre-4.8.0 Core classification;
• incident checkpoint mismatch;
• build-identity validation;
• isolation from Bitcoin/non-RVN coin classes;
• KAWPOW nHeight enforcement;
• testnet/mainnet distinction;
• legacy Electrum handler preservation;
• daemon status caching and RPC call behavior.

The repository's existing pull-request CI additionally runs the full pytest suite, pycodestyle and documentation build.

Acceptance criteria

1. The code is merged or otherwise incorporated into Cipig's ElectrumX tree.
2. Existing/legacy Electrum clients continue to work unchanged.
3. Other coins in the multi-coin installation remain unaffected.
4. The updated code is deployed/restarted for all three RVN endpoints listed above.
5. server.ravencoin_backend is verified live on each of the three endpoints.
6. Each endpoint reports the real Core version/backend evidence of its configured ravend.

Scope

The final diff is intentionally small and self-contained: one Ravencoin backend module, one RVN-only activation block in the environment, and focused tests. No generic Electrum protocol implementation has been replaced.