multilevel: a chain with any writable level is writable

[tycho]

Fixes #2773.

MultiLevelStorage::check() starts from ReadWrite and demotes the composite to ReadOnly as soon as any level reports ReadOnly. The server then wraps the entire storage in ReadOnlyStorage ("server has setup with ReadOnly"), so every cache write is refused before any write-error policy is consulted -- including writes to writable levels, and preprocessor cache updates ("Failed to update preprocessor cache: Cannot write to read-only storage").

This inverts the documented semantics: docs/MultiLevel.md says read-only levels are "automatically skipped during writes, regardless of write policy", and put() already implements exactly that per-level skipping. The practical fallout is that the documented read-only fallback topology -- a fast writable local disk in front of a read-only shared remote (SCCACHE_S3_RW_MODE=READ_ONLY, or an Azure SAS token without write permission, which fails the startup write probe and is treated as read-only) -- silently stops populating the local disk cache entirely.

Reproduction (hello-world C compile, sccache 0.16.0):

chain	server mode	local disk written
disk	ReadWrite	yes
disk, s3/azure (read-only)	ReadOnly	no
disk, s3/azure (read-write)	ReadWrite	yes

The fix aggregates in the other direction: the composite is writable when any level is writable, and read-only only when every level is read-only. put() needs no changes -- it already routes writes only to writable levels under all three write-error policies.

Tests: the existing test_readonly_level_in_check (single-level, all-read-only chain) still passes; added test_mixed_readonly_chain_is_readwrite_in_check (writable+read-only in both orders) and test_all_readonly_chain_is_readonly_in_check.

Verified end to end against a real Azure container with a read-list-only SAS token: with this fix the same config that previously wrote nothing populates the local disk tier, and remote hits backfill to disk as documented.