oidc/init: include cause in re-thrown errors

[alxndrsn]

Noted while working on #1230.

This makes logged errors more useful.

Example logging

Before

attempted to log Sentry exception in development:
Error: Failed to configure OpenID Connect client: TypeError: fetch failed
    at initClient (/home/user/workspaces/odk/backend/lib/util/oidc.js:123:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async /home/user/workspaces/odk/backend/lib/resources/oidc.js:108:22

After

attempted to log Sentry exception in development:
Error: Failed to configure OpenID Connect client
    at initClient (/home/user/workspaces/odk/backend/lib/util/oidc.js:123:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async /home/user/workspaces/odk/backend/lib/resources/oidc.js:108:22 {
  [cause]: TypeError: fetch failed
      at node:internal/deps/undici/undici:13484:13
      at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
      at async discovery (file:///home/user/workspaces/odk/backend/node_modules/openid-client/build/index.js:151:16)
      at async initClient (/home/user/workspaces/odk/backend/lib/util/oidc.js:65:20)
      at async /home/user/workspaces/odk/backend/lib/resources/oidc.js:108:22 {
    [cause]: Error: connect ECONNREFUSED 127.0.0.1:9898
        at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1615:16) {
      errno: -111,
      code: 'ECONNREFUSED',
      syscall: 'connect',
      address: '127.0.0.1',
      port: 9898
    }
  }
}

What has been done to verify that this works as intended?

Run locally & run tests.

Why is this the best possible solution? Were any other approaches considered?

No other approaches were considered.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

This change should only affect environments with Sentry disabled. If third-party deployments are parsing stderr for e.g. monitoring, this may affect them.

Does this change require updates to the API documentation? If so, please update docs/api.yaml as part of this PR.

This change does not affect the public API.

Before submitting this PR, please make sure you have:

• run make test and confirmed all checks still pass OR confirm CircleCI build passes
• verified that any code from external sources are properly credited in comments or that everything is internally sourced

[matthew-white]

Looks good to me. 👍