DurabilityState
Whether a Bolt is meeting the durability level it promised.
Relative, not absolute, and that is the whole design. A bolt that promised nothing — an in-memory archive, or a mapped one told to let the operating system flush when it likes — is AsPromised forever, because nothing it said can be broken. A bolt that promised to flush every record before returning, and then could not, is Degraded. The question this answers is "is this archive still doing what it said", not "are these bytes on a platter".
The absolute reading was considered and rejected. It would have every in-memory bolt report "not durable" permanently on every target — true, unactionable, and it would make the conformance property special-case every backend that can never reach the confirmed state.
Why this is not on AppendResult, and not on BoltAvailability
A flush covers a range of pages. When it fails, the frames at risk are everything since the last successful flush — earlier appends that already returned AppendResult.Written are equally at risk, and those results are in the consumer's past. Hanging non-durability off the one append that happened to trigger the flush both understates the damage and misattributes it. A return value is also consumed once and cannot be re-queried, which is structurally wrong for a fact that may arrive once and must survive: on Linux an EIO from msync may be reported once and then cleared, so a swallowed flush failure destroys the only notification that will ever come.
Bolt.availability answers "can this bolt write now", and a failed flush does not stop writes. Folding the two together would have a consumer stop feeding a bolt that is still perfectly able to accept records — the "lost from both sides" harm the module exists to prevent.