Clarify validator behavior when metadata state is not ready during scoring

[it-education-md]

I found a validator/metadata edge case that looks real, but the correct fix depends on intended validator policy.

Today, the validator can still proceed into scoring even when metadata state is not clearly ready yet. That may be acceptable if scoring continuity is preferred, or it may be a bug if the goal is to avoid false miner penalties caused by incomplete metadata state.

Before opening a PR, I want to confirm which behavior is intended.

Current behavior

• MetadataManager runs in a background thread and stores miner metadata in a local JSON state file.
• If the state file is missing or unreadable, it falls back to an empty in-memory state with last_full_sync = None.
• The validator only skips scoring when last_full_sync exists and is older than 2 hours.
• If last_full_sync is None, scoring can still proceed.
• During miner validation, missing metadata causes miners to be penalized to zero weight.

This means scoring may run while:

• the initial metadata sync has not completed
• the local metadata state failed to load
• the current metagraph includes UIDs not yet reflected in local metadata state
• some metadata queries failed during sync

Risk

This creates a possible false-penalty path where a miner is penalized because local metadata is incomplete or not ready, not necessarily because the miner actually lacks metadata on-chain.

Possible fix directions

1. Strict readiness gate

Block scoring until metadata has completed a fresh successful sync.

Pros:

• avoids false metadata-based penalties

Cons:

• may skip scoring epochs if metadata is not ready

2. Soft recovery

Keep scoring behavior mostly unchanged, but make metadata handling safer:

• atomic JSON state writes
• quarantine corrupt state files
• preserve existing metadata on query failure
• improve readiness/error logging

Pros:

• lower operational impact
• closer to current behavior

Cons:

• still allows scoring with partially uncertain metadata state

3. Hybrid approach

Harden metadata state handling and only block scoring for the most dangerous cases, such as:

• corrupt initial state with no successful sync yet
• incomplete first metadata bootstrap

Which behavior is preferred here?

Should validator scoring continue when metadata sync has not completed successfully, or should scoring be blocked to avoid false miner penalties?

[it-education-md]

@xzistance Could you please take a look at this issue? I’d be happy to work on it if you think it’s worth pursuing. Please let me know!