refactor(settings): dedupe positive-integer env-var parsing

[pedrofrxncx]

Source: reduction — hunted for validation gaps in apps/api/src/settings/resolve-config.ts (the DUCKDB_THREADS validation gap I found there is already covered by open PR #5130, so I didn't duplicate it) and found this duplication instead while reading the file end to end.

toPositiveIntegerOrDefault and toPositiveIntegerOrUndefined had byte-identical parse-and-throw bodies (parse Number(value), validate Number.isSafeInteger(...) && > 0, throw "${name} must be a positive integer"), differing only in what they return when value is unset/empty (a caller-supplied default vs. undefined). Now toPositiveIntegerOrDefault just delegates to toPositiveIntegerOrUndefined(...) ?? defaultValue — same validation, same error message, same call sites (PORT, DATABASE_POOL_MAX, CLICKHOUSE_MAX_MEMORY_USAGE, NATS_TUNNEL_SESSION_TTL_SECONDS, STUDIO_SEAT_ALLOWANCE_CENTS, STUDIO_TOPUP_FEE_PERCENT), net -6 lines.

Behavior is unchanged: all 58 existing tests in resolve-config.test.ts pass without modification, including the it.each(["abc", "0", "-1", "1.5", "Infinity"]) cases that exercise both the default- and undefined-returning call sites.

To confirm: bun test apps/api/src/settings/resolve-config.test.ts.

Locally ran: bun run fmt, cd apps/api && bunx tsc --noEmit (clean), and the targeted test file above (58 pass). Full CI validates the rest.

---

Summary by cubic

Deduped positive-integer env var parsing by having toPositiveIntegerOrDefault call toPositiveIntegerOrUndefined and apply the default. Validation and error messages stay the same; behavior is unchanged.

• Refactors
  • Centralized parse-and-validate logic in toPositiveIntegerOrUndefined.
  • toPositiveIntegerOrDefault now returns toPositiveIntegerOrUndefined(...) ?? defaultValue.
  • No changes to existing env var behavior.

^{Written for commit d413b4c. Summary will update on new commits.}