Static HKDF salt "RATLS" with no key versioning

The disk encryption key derivation in `dstack/kms/src/main_service.rs` uses a hardcoded, empty HKDF salt rather than a per-instance random salt, reducing HKDF's security margin and making all derived keys deterministic given the same input keying material.

## Root Cause

The RA-TLS key derivation uses a hardcoded salt `b"RATLS"` for all HKDF operations. There is no key versioning mechanism and no support for key rotation. If the HKDF input keying material (IKM) is compromised at any point, all historically derived keys are also compromised because the salt is static and publicly known.

```rust
// kdf.rs:28
const SALT: &[u8] = b"RATLS";
```

## Attack Path

1. Attacker compromises the HKDF input keying material (e.g., via a KMS vulnerability)
2. Because the salt is static and hardcoded, the attacker can re-derive all keys ever produced by this KDF
3. No key versioning means there is no way to distinguish keys from different epochs
4. Key rotation requires changing the IKM, but old keys remain derivable from old IKM + static salt

## Impact

No forward secrecy in the key derivation hierarchy. Compromise of the IKM at any point reveals all past and future derived keys. The static salt provides no additional entropy or domain separation beyond what the IKM already provides.

## Suggested Fix

1. Include a version number in the salt or info parameter: `format!("RATLS-v{}", version)`
2. Support key rotation by allowing the salt to be updated periodically
3. Consider using a random salt persisted alongside the derived keys

---
> **Note:** This issue was created automatically. The vulnerability report was generated by Claude and has not been verified by a human.

先閱讀 dstack/kms/src/main_service.rs 和 kdf.rs:28 中的 KDF 程式碼，以確認靜態 salt 的使用方式，以及所回報的影響是否適用。該 issue 提議進行版本控管、輪替或持久化隨機 salt，但沒有選定設計；完成工作需要一個已達成共識的金鑰衍生與輪替方案，以及相應的驗證。

由索引模型根據 Issue 內容生成。