feature: support both WebID-TLS and Solid-OIDC authentication simultaneously

Summary

Currently NSS only supports one authentication method at a time (--auth tls OR --auth oidc). It would be valuable to support both simultaneously.

Current Behavior

// lib/create-app.mjs:335-339
const auth = argv.forceUser ? 'forceUser' : argv.auth
if (!(auth in API.authn)) {
  throw new Error(`Unsupported authentication scheme: ${auth}`)
}
await API.authn[auth].initialize(app, argv)  // Only ONE method initialized

Proposed Behavior

Initialize both auth handlers and let them chain naturally:

async function initAuthentication(app, argv) {
  // Initialize both handlers
  await API.authn.oidc.initialize(app, argv)
  await API.authn.tls.initialize(app, argv)
}

The handlers already call next() when they don't find their credentials, so they'd naturally fall through to the next method.

Benefits

1. Flexibility - Different clients can use different auth methods against the same server
2. Migration path - Users can transition gradually between auth methods
3. Spec compliance - Solid doesn't mandate one auth method over another
4. Client compatibility - Legacy TLS clients and modern OIDC clients work together

Implementation

The change is minimal:

• Remove the either/or logic in initAuthentication()
• Initialize both handlers (or make it configurable: --auth oidc,tls)
• Auth chain: OIDC → TLS → anonymous

Prior Art

JavaScriptSolidServer (JSS) already supports this - it tries auth methods in sequence:

1. Solid-OIDC (DPoP tokens)
2. WebID-TLS (client certificates)
3. Bearer tokens

Works well and provides maximum flexibility.

Comienza en lib/create-app.mjs:335-339 y luego inspecciona los puntos de entrada de inicialización de API.authn.oidc y API.authn.tls. Verifica cómo cada handler llama a next() cuando faltan las credenciales y define la finalización como el hecho de que tanto los clientes WebID-TLS como los de Solid-OIDC se autentiquen contra el mismo servidor.