feat(node): expose attestation-freshness metrics on /metrics

[barakeinav1]

Background

In the 3.13.x incident, collateral fetches failed for hours and every TEE node was ~24h from being silently dropped from the participant set. Nothing alerted — we found it by hand-querying get_attestation. The node publishes no signal for how stale its attestation is.

Node side only; the Grafana/Prometheus half is https://github.com/near/mpc-private/issues/559, which needs upgraded nodes first.

Proposed design. Two gauges, written where the node already confirms a submission on chain (#3736):

• the expiry the contract stores for our TLS key — how long until eviction;
• when a submission last landed — how long re-attestation has been failing.

Both as absolute Unix timestamps rather than remaining durations, so a gauge frozen by a node that stopped re-attesting keeps decaying towards now and still trips its threshold. A single failed attempt is absorbed by the next hourly retry, so only sustained failure moves the signal. Documented thresholds stay relative to the configured expiry window rather than hard-coded, so they survive changes to it (cf. #3947).

Acceptance Criteria

• The node exposes attestation freshness on /metrics.
• The signal distinguishes a sporadic failure from a sustained one.
• Metrics and suggested alert thresholds are documented for operators.

Resources & Additional Notes

• PR: feat(node): metrics for attestation freshness #4236
• Related: feat(tee-authority): reject PCCS collateral older than 7 days #3049, fix(node): confirm submit_participant_info via advancing attestation expiry #3736, fix(attestation): revert DEFAULT_EXPIRATION_DURATION_SECONDS from 1 day back to 7 days #3947, and feat(metrics): expose the TEE image-hash allowlist expiry metrics #3752 whose gauge/sentinel convention this follows.
• DCAP freshness design doc, Gap 4 (no observability): near/mpc-private research/dcap-collateral-freshness.
• mpc_tee_attestation_attempts_total (feat: add metrics for TEE attestation generation attempts #2727) and mpc_own_image_hash_* (feat(metrics): expose the TEE image-hash allowlist expiry metrics #3752) already exist — the freshness family is what's missing.

[netrome]

Very important, setting as P1

[barakeinav1]

We already have part of this — flagging before anyone builds a redundant metric

The node already emits attestation metrics on /metrics:

• mpc_tee_attestation_attempts_total{outcome="success"|"failure"} — crates/node/src/metrics.rs, set by the periodic loop in tee/remote_attestation.rs. A collateral-freshness rejection increments outcome="failure", so this would have caught the recent stale-CRL incident (failure rising each interval while success flatlines).
• mpc_own_image_hash_allowed / mpc_own_image_hash_is_most_recent / mpc_own_image_hash_expiry_timestamp_seconds.

But I'm not sure it's enough:

• It counts attestation generation attempts, not the on-chain attestation expiry / time-since-last-successful-submission — it doesn't directly say "our attestation lapses at T and the node gets kicked."
• mpc_own_image_hash_expiry_timestamp_seconds is a different deadline (image-allowlist eviction, not attestation expiry).
• Most importantly, no alert is wired on any of these — which is exactly why the incident went unnoticed until it was found by hand.

So the highest-value work here is likely: (1) wire an alert on mpc_tee_attestation_attempts_total{outcome="failure"} (rising) / success (flatlined), and (2) consider adding an explicit attestation-expiry gauge for the "how long until we're kicked" signal. Adjusting the scope of this issue accordingly rather than adding a from-scratch metric.

[netrome]

Bumping to P0 in light of the recent emergency release.