fix: declare @nrfcloud/validate-with-typebox as a runtime dependency

[coderbyheart]

Moves @nrfcloud/validate-with-typebox from devDependencies to
dependencies.

The bug

problemResponse.ts, validateInput.ts and validateResponse.ts all import
@nrfcloud/validate-with-typebox, but it is declared as a devDependency, so
the published package does not pull it in. Consumers that do not independently
have it in their tree fail at import time.

Reproduced against the currently published @nrfcloud/lambda-helpers@1.0.30,
installing it the way a Lambda layer does — only the listed dependencies, no dev
dependencies:

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@nrfcloud/validate-with-typebox'
  imported from …/node_modules/@nrfcloud/lambda-helpers/npm/problemResponse.js

With this change the same install pulls in problem-detail and
validate-with-typebox, and the import succeeds.

Why it only appeared now

While this package was published to JSR, JSR's NPM compatibility build derived
the dependency list from the actual imports, so it shipped
@jsr/nrfcloud__validate-with-typebox as a runtime dependency no matter how it
was declared here — it is still visible in the published
@jsr/nrfcloud__lambda-helpers@1.0.28
metadata. Publishing to NPM uses the declared dependencies verbatim, which
exposed the long-standing mis-declaration.

How it was found

account-service-next builds its Lambda layers from an explicit subset of
dependencies. Its cognitoAuthLayer lists @nrfcloud/lambda-helpers but not
@nrfcloud/validate-with-typebox, so the authorizer Lambdas could not resolve
it, failed to initialise, and API Gateway answered every authorized request with
AuthorizerConfigurationException.

All six of the migrated libraries were audited for the same class of problem;
this is the only one affected.

Verified locally

The type check, tests and build pass, and npm ci reinstalls from the
regenerated lock file.

[coderbyheart]

Non-significant change, no PR review required.