fix(core): classify "service unavailable" as transient for bulkWrite retry

[yinlianghui]

Baseline and relation to #2678/#2680

• Verified at 98874656ffc50ce1531af52346228ffcdda73fba.
• defaultIsTransientError was introduced by perf(seed,import): route bulk writes through the engine's batch insert path #2680 (21420d9f82e) to satisfy perf/reliability: seed + data-import bypass the engine's bulk-insert path → N round-trips, N summary recomputes, no transient retry #2678's transient retry acceptance criterion; the affected file is unchanged after that merge.

Minimal reproduction

defaultIsTransientError(new Error('service unavailable'))
// actual: false

The QA harness executed this twice with the same result.

Expected / actual

• Expected: a standard availability failure is classified transient and receives the configured retry attempts.
• Actual: /server.*unavailable/i does not match service unavailable; the batch degrades immediately, and identical per-row failures are not retried.

Impact

A common 503-style message can drop seed/import rows despite #2678's reliability acceptance criterion.

Evidence and exclusions

• Source: packages/core/src/utils/bulk-write.ts, TRANSIENT_PATTERNS.
• Existing code/status-based cases (503, fetch failed, connection reset, timeout) remain outside this finding and passed QA.
• This issue does not claim every arbitrary “unavailable” message is transient; the classifier should cover the established service-availability signature without retrying validation/constraint failures.

Required regression test

Add a classifier matrix case for service unavailable, plus a bulkWrite attempt-count test proving it retries while logical errors still do not.