Censorship resistance in the KMS

## Summary
There is a [discussion](https://github.com/Dstack-TEE/dstack/pull/91#discussion_r1937196136) about ensuring censorship resistance in the KMS de-registration process, particularly focused on preventing scenarios where a vulnerable KMS instance continues operating because it's being prevented from seeing de-registration transactions.

## Problem Statement
A critical security vulnerability scenario:
1. A vulnerability is discovered in KMS and the corresponding measurement is de-registered on-chain
2. Existing KMS instances are blocked from processing new blocks by an attacker
3. The KMS instances never see the de-registration transaction and continue operating
4. Attackers have unlimited time to extract the root secret
5. The de-registration effectively becomes useless

## Proposed Solutions

### On-chain Interaction Requirements
- KMS must interact with the chain at startup and periodically thereafter
- Limit the number of actions allowed without forcing an on-chain interaction
- Require a random nonce to appear on-chain periodically

### Trusted Time Sources Alternative
- Use NTS or similar trusted time sources

## Considerations
- On-chain interactions are costly and involved
- Need to ensure NTS cannot be replayed or delayed in ways that defeat verification
- Verification is only as reliable as the trusted time source