Clarify that `null` is never exposed to the page

[pes10k]

This issue is being filed as part of the PING review requested here https://github.com/w3cping/privacy-request/issues/136

The current text notes that there is a null slot on the document interface. However, the security and privacy considerations section notes that the only possible values are "continuous" and "folded", and that user agents should return the former by default. This seems (at least on first read) as contradictory and at least potentially confusing

From the discussion on the PING call, my understanding is that there are no cases where the browser should return null to the page from this API (with the possible exception of WebDriver cases, though I dont understand why this is needed either; why not also return "continuous" in this case). Limiting the API to only two values is ideal from a privacy perspective to limit fingerprinting surface here.

[rakuco]

I think different concepts are being mixed up here:

• The API (i.e. DevicePosture.type) always returns either "continuous" or "folded". These are the only members of the DevicePostureType enum. The value is tracked internally in the [[CurrentPosture]] internal slot of the Document interface.
• Top-level traversables (not the Document interface) have an additional [[PostureOverride]] internal slot whose type would be, in Web IDL terms, DevicePostureType? (i.e. a nullable DevicePostureType). null is used to indicate that the internal slot has a value, but the [[PostureOverride]] internal slot is never returned directly to script, nor is that stated anywhere in the spec.
• Specifically, [[PostureOverride]] is used in Calculating the device posture information, which always returns a DevicePostureType -- there's a check there that returns [[PostureOverride]]'s value when it is not null.

We could add a note to the table defining [[PostureOverride]] stating that null is never exposed to script, but I thought that was already clear given DevicePosture.type's IDL type.

(cc @JuhaVainio)