Read the Dev Drive designation as volume flags, not as localized text

[ALERTua]

Closes #111
Closes #105

The run decided whether the new Dev Drive was trusted by matching an English sentence in fsutil devdrv query output. That sentence is localized, so on the German machine in #3 every successful run ended like this:

Marked E: as trusted. Reading it back only works in English, and this machine
answers in its own language, so the run cannot confirm it here.
fsutil devdrv query E: said:
  Dies ist ein vertrauenswürdiges Entwicklervolume.
If that says the volume is a trusted developer volume, everything is as it should be.

Windows carries the designation as two documented bits instead:

#define PERSISTENT_VOLUME_STATE_DEV_VOLUME     (0x00002000)
#define PERSISTENT_VOLUME_STATE_TRUSTED_VOLUME (0x00004000)

Both come back from one FSCTL_QUERY_PERSISTENT_VOLUME_STATE call, and a bit has no language.

What a run now prints

Dev Drive F: carries the trusted designation, which is the signal for Microsoft Defender to run in performance mode.
All done. Dev Drive F: ready.

Two states the script could not tell apart before now have their own answers:

F: is a Dev Drive, but the volume does not carry the trusted designation.
It still works; anti-virus filters stay attached to it.
Retry by hand with: fsutil devdrv trust /f F:

G: does not carry the Dev Drive designation, although it was formatted as one.
Nothing that depends on that designation applies, Defender performance mode included.
Done, but G: does not carry the Dev Drive designation. See above.

The last one is a question nothing here could ask before: a format that did not produce a Dev Drive passed unnoticed, and the run still ended "All done".

#105, which this also closes

The trust report used to call a non-zero exit code a failure while printing the volume saying otherwise. It now reads the volume and reports that. fsutil is asked for text only where the flag read itself fails, and in that path the report states the exit code without turning it into a verdict.

Reproduced live, on a scratch NTFS volume: fsutil devdrv trust /f returned exit code 1, and the run named what was actually wrong rather than announcing a failure to mark it.

Measured, on scratch .vhdx volumes

State	VolumeFlags	dev	trusted
Dev Drive straight after Format-Volume -DevDrive	0x00006001	yes	yes
the same volume after fsutil devdrv untrust	0x00002001	yes	no
after fsutil devdrv trust /f again	0x00006001	yes	yes
plain NTFS	0x00000000	no	no

The trusted bit follows trust and untrust exactly. The read needs no administrator rights, while the per-volume fsutil devdrv query does.

Three things must be right at once, and an earlier attempt had all three wrong — which is why AGENTS.md and the plan both recorded that no language-independent signal existed:

• the control code is function 143. The earlier attempt used 141, found by sweeping numbers until one answered; 141 answers and returns zeros. (142 is the write.)
• the handle must be the volume's root directory, \\?\X:\ with FILE_FLAG_BACKUP_SEMANTICS. The raw device refuses this code.
• Version must be 1, and FlagMask must be 0xFFFFFFFF — a mask naming the two Dev Drive bits is refused outright on NTFS, which does not know them.

AGENTS.md and README.md are corrected accordingly.

Tested

794 Pester tests pass (786 before), analyzer clean, parse clean.

Eight deliberate breakages were run, each in its own process, and seven were caught: the control code back to the sweep number, the mask narrowed, the handle opened without backup semantics, a short answer trusted, the flags dropped from the report call, the Dev Drive bit no longer asked first, fsutil asked unconditionally, and the run called done whatever the verdict. The one not caught is the short-answer guard, which cannot be reached from a real volume.

Beyond the unit suite, the sequence itself was run on real volumes — the four functions lifted out of the syntax tree, dev_drive.ps1 never executed. The trust call force-dismounts the volume and the flag read follows with nothing in between; had that left a window, every real run would have fallen into the "could not read" path while the whole suite stayed green. Twenty reads fired back to back straight after the dismount, across two volumes, and every one answered. All three screens above are copied from that run.