AuthScheme enum is unreachable from the package root, so AuthGuardedMultisigConfig cannot be constructed

[WiktorStarczewski]

AuthGuardedMultisigConfig takes the wasm AuthScheme enum, but that enum cannot be imported from the package root — a string-valued const of the same name shadows it, so every JS caller passes undefined and the constructor rejects it.

Symptom

Error: invalid enum value passed
  at miden_client_web.wasm.authguardedmultisigconfig_new
  at new AuthGuardedMultisigConfig

Repro

import { AuthScheme, AuthGuardedMultisigConfig } from '@miden-sdk/miden-sdk';
AuthScheme.AuthEcdsaK256Keccak;                                  // undefined
new AuthGuardedMultisigConfig(approvers, 1, guardian, AuthScheme.AuthEcdsaK256Keccak);  // throws

Cause

dist/*/index.js re-exports the wasm module first and api-types second, so the later definition wins:

crates/miden_client_web.js	enum AuthScheme { AuthEcdsaK256Keccak = 1, AuthRpoFalcon512 = 2 }
api-types.js	const AuthScheme = { Falcon: "falcon", ECDSA: "ecdsa" } ← exported

Expected

AuthGuardedMultisigConfig should take the string scheme like the rest of the friendly API — resolveAuthScheme(scheme, wasm) in js/utils.js is already the established convention for exactly this, and AuthScheme.ECDSA / AuthScheme.Falcon are what the api-types doc comment tells callers to use.

Impact

Introduced in 0.16.0-rc.7 with createAuthGuardedMultisig. Every JS consumer of guarded multisig accounts hits it. Workaround is to inline the discriminants ({ ecdsa: 1, falcon: 2 }), which is what OpenZeppelin/guardian#450 currently does.

[Mabolla]

I'd like to work on this if it's available.

My proposed approach is to update the guarded-multisig configuration path to accept the public string-valued AuthScheme API and resolve it through the existing resolveAuthScheme convention before calling the WASM binding. This would keep the internal WASM enum from colliding with the package-level public export.

I would also add browser and Node regression coverage for both AuthScheme.ECDSA and AuthScheme.Falcon, including construction through the package root.

Would this scope be appropriate, and may I take the issue?