Distinguish Soroban from classic state in "Why local disk stays bounded"

State archival is a Soroban-only mechanism — only contract data and
contract code entries carry a rent balance and get evicted. Classic
ledger entries (accounts, trustlines, offers, claimable balances,
liquidity pool shares, data entries) don't expire. The previous text
implied the rent model applied universally, which is wrong.

Split the explanation into two paragraphs: one for Soroban entries
(bounded by archival), one for classic entries (bounded by reserve
requirements as anti-spam friction). Keep the practical bottom line
that the working set still lands in the 30-60 GB range.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: rice2000

docs/validators/admin-guide/prerequisites.mdx

@@ -88,7 +88,9 @@ A working set of roughly 30–60 GB is typical. The 100 GB local NVMe included w
 
 A common misconception is that validators need to provision storage proportional to network history. They do not.
 
-**Live ledger state is bounded by [state archival](https://developers.stellar.org/docs/learn/encyclopedia/storage/state-archival).** Every entry on the ledger has a rent balance; when the balance reaches zero, the entry is archived and removed from the live state. Validators store the live state plus a small "Hot Archive" of recently archived entries; when the Hot Archive fills, it is published to the History Archive, the validator retains only the Merkle root of the published tree, and the archived entries themselves are deleted from the validator. The result is that local validator state stays compact even as cumulative network history grows.
+**Soroban (smart contract) state is bounded by [state archival](https://developers.stellar.org/docs/learn/encyclopedia/storage/state-archival).** Contract data and contract code entries carry a rent balance; when the balance reaches zero, the entry is archived and removed from live state. Validators store the live Soroban state plus a small "Hot Archive" of recently archived entries; when the Hot Archive fills, it is published to the History Archive, the validator retains only the Merkle root of the published tree, and the archived entries themselves are deleted from the validator.
+
+**Classic ledger entries — accounts, trustlines, offers, claimable balances, liquidity pool shares, and data entries — do not expire.** They persist on the live state indefinitely. They grow slowly, though, because [reserve requirements](/docs/learn/fundamentals/stellar-data-structures/accounts#base-reserves-and-subentries) act as anti-spam friction on creation. In practice, the resulting working set still lands in the 30–60 GB range cited above, so local validator state stays compact even as cumulative network history grows.
 
 **History archives live on object storage, not on the validator.** Full validators publish history archives to a separate object store (S3, R2, Backblaze B2, etc.) — that's where the multi-TB archive data lives. The validator process itself doesn't hold the archive on its local disk. See [Publishing History Archives](/docs/validators/admin-guide/publishing-history-archives) for the recommended setup.