fix: detect WebAuthn extensions by asking the browser

[NiKrause]

Closes #9.

The bug

checkExtensionSupport() asked 'largeBlob' in PublicKeyCredential.prototype. Extensions are never properties of that interface — they arrive through getClientExtensionResults() — so the test answered false in every browser ever shipped, including ones with complete support. hmacSecret sat beside it hard-coded to false.

Together that permanently disabled keystore encryption: the demo's "Encrypt keystore with WebAuthn" checkbox is disabled when neither flag is set, so the demo could not demonstrate its own headline feature anywhere.

Measured, not assumed

On Chrome 148, on the deployed demo page:

Extension	in PublicKeyCredential.prototype	getClientCapabilities()
largeBlob	false	true
prf	false	true
hmacCreateSecret	false	true

Probing appid, credBlob and credProps the same way also returns false, and the prototype carries only rawId, response, authenticatorAttachment, getClientExtensionResults, toJSON, constructor. So this was never a vendor quirk — the question was asked of the wrong object, and no browser could have passed it.

What this says about #9

The crash #9 reported — No hmac-secret output from credential — did stop happening. But not because anything was fixed: the path became unreachable once the detection answered false everywhere, which took the working paths with it. The feature went quiet, not well. This restores it.

Changes

• checkExtensionSupport() reads getClientCapabilities(), reports prf alongside the other two, and returns known — distinguishing the browser says no from the browser cannot say. Treating the second as a refusal is exactly how a working feature gets disabled; callers should attempt the ceremony instead.
• extensionSupportFromCredential(credential) (new) reads what the authenticator actually agreed to, from the registration response. Client support is not authenticator support: a browser may support largeBlob while the key in front of it does not. Only the ceremony settles it, and the answer belongs to the credential, so it should be stored with it.
• addLargeBlobToCredentialOptions() takes an optional support level. Still 'required' by default — under 'preferred' an unsupported authenticator yields a credential whose secret was never written, which loses the keystore silently.
• The demo offers PRF and prefers it, matching the library's default since 0.4.0. It had hard-coded largeBlob, overriding that default and never exercising PRF. Methods the browser cannot vouch for now read "Unknown" rather than "Not supported", and stay selectable.

Verification

• 57 node tests pass (45 before; 12 new), including the old prototype probe kept as an explicit regression guard
• format:check and lint clean
• the encrypted-keystore demo builds

Still worth a manual pass on the deployed demo once this lands: tick "Encrypt keystore with WebAuthn" and confirm it completes. That is the part no test here covers.