guest SDK: six modules are executed by no gate (including rsa_oaep)

[lann]

The conformance guests call the raw lann_webcrypto_guest::bindings::* surface exclusively, so SDK-wrapper execution comes only from examples/crypto-demo, whose imports cover 15 of 21 modules. Never executed anywhere: aes_cbc.rs, hmac_sha1.rs, hkdf_sha1.rs, pbkdf2_sha1.rs, sha1_checked.rs, and rsa_oaep.rs (99 lines, landed with 6d3ab7e — has never run).

These are thin forwarders, but the SDK is a published library surface. Cheapest close: extend crypto-demo's checks to touch each module (the gated ones already build with features enabled in test builds).

[lann]

#328 executes five of the six: aes_cbc, hmac_sha1, hkdf_sha1, pbkdf2_sha1 (known-answer checks against SP 800-38A F.2.1, RFC 2202, RFC 5869 A.4, RFC 6070), and sha1_checked (bimodal: the FIPS 180 'abc' answer where the constructors are served — wasmtime, composed — and the documented fail-closed unsupported decline on jco; the demo now carries the gated import).

rsa_oaep is structurally blocked from the same close: the issue's premise that crypto-demo can 'touch each module' fails for it. Executing any rsa_oaep wrapper adds the rsa-oaep-encrypt import to the component, and the in-guest provider withholds that interface (class D), so the composition demo::test-composed gates on stops building at wac plug — one demo artifact cannot both execute the module and compose. Its wrapper execution needs a home that never composes with the provider: the only candidates today are a host-only second guest (new example surface) or waiting for a consumer of the OAEP encrypt path with its own gate. Leaving this open scoped to rsa_oaep.rs alone.