fix(relayer): default wallet-job concurrency to the wallet count

[harrymove-ctrl]

Problem

WALLET_JOB_CONCURRENCY was read in two separate places in main.rs, each
falling back to its own hard-coded 8:

// main.rs:1371 — advisory-lock pool
.unwrap_or(8).saturating_add(1).max(2)
// main.rs:1593 — Apalis worker count
.unwrap_or(8)

Meanwhile the TS sidecar sizes its Walrus upload semaphore from a completely
different source — the wallet count:

// scripts/sidecar/config.ts:219
export const WALRUS_UPLOAD_MAX_CONCURRENCY = parsePositiveIntEnv(
    "WALRUS_UPLOAD_MAX_CONCURRENCY",
    Math.max(1, SERVER_SUI_PRIVATE_KEYS.length || 1), 1, 100);

Two processes, two unrelated defaults for one number, and nothing logged the
resolved value. Production drifted to WALLET_JOB_CONCURRENCY=7 against 8
upload slots (8 wallets, WALRUS_UPLOAD_MAX_CONCURRENCY unset) — nobody
picked that pair, and answering "which limiter actually binds?" currently
means reading two languages plus the Railway env.

Change

Resolve the number once, in types::wallet_job_concurrency_from_env:

• WALLET_JOB_CONCURRENCY wins when set — production sets it on Railway and
  that stays the source of truth
• unset falls back to the wallet count, the same derivation the sidecar
  uses, so the two processes cannot drift to different hard-coded defaults
• clamped to 100, mirroring the sidecar's clamp
• 0 wallets still yields one worker, so the queue drains into a clear
  per-job error instead of stalling

main.rs now derives both the worker count and the advisory-lock pool from
that single value, and logs it at boot — it was previously invisible. When
concurrency exceeds the wallet count it warns, because the sidecar allows one
upload per wallet (WALRUS_UPLOAD_PER_WALLET_CONCURRENCY, default 1), so
the surplus jobs only queue on its semaphore rather than adding throughput.

Behaviour

WALLET_JOB_CONCURRENCY	wallets	before	after
7 (production today)	8	7	7 — unchanged
unset	8	8	8 — unchanged
unset	3	8	3
500	8	500	100

No change for production as configured. The fallback only moves when the
wallet count is not 8, which is exactly the drift this removes.

Tests

5 new unit tests on the pure resolver in types.rs, all passing:

test types::tests::wallet_job_concurrency_prefers_the_configured_value ... ok
test types::tests::wallet_job_concurrency_falls_back_to_the_wallet_count ... ok
test types::tests::wallet_job_concurrency_ignores_unusable_values ... ok
test types::tests::wallet_job_concurrency_stays_within_the_sidecar_clamp ... ok
test types::tests::wallet_job_concurrency_keeps_one_worker_without_wallets ... ok

cargo check --bin memwal-server clean. cargo fmt --check reports no diff in
the touched files (the two pre-existing diffs in storage/sui.rs are on dev
and left alone).

Not addressed here

The redundant SERVER_SUI_PRIVATE_KEY (singular) alongside the plural form.
It is dead config for the sidecar — config.ts:85 only reads it when the
plural list is empty — but types.rs:677,688 still uses it as a Rust-side
fallback, so removing it needs its own check.