disable coredumps in fuel-core-bin to keep pod restarts fast (#3301)

Rocksdb's C++ static destructors race fuel-core's own DB teardown during
libc atexit, raising SIGABRT with "pthread lock: Invalid argument". The
application-level shutdown has already completed cleanly at that point
(WAL synced, sub-services drained, runtime workers joined), and rocksdb
recovers from the WAL on the next start — so the abort is functionally
harmless. But the SIGABRT triggers a kernel coredump of fuel-core's full
RSS (~2.5 GB on devnet), and writing that out dominates Kubernetes
pod-restart time: ~60 s with the coredump vs ~6 s without.

Validated on devnet: with `core_pattern` redirected so the kernel
discards the coredump pipe, restart of an authority pod consistently
takes 6-8 s. With the default systemd-coredump pipe handler, the same
restart takes 57-86 s. The fuel-core process itself exits in the same ~5
s either way.

Since the coredump produces no actionable diagnostic (it's the rocksdb
static-destructor race, not a fuel-core bug), disable it via
`setrlimit(RLIMIT_CORE, 0, 0)` early in `main`. An escape hatch
`FUEL_CORE_ENABLE_COREDUMP=1` keeps coredumps on for cases where a
genuine crash needs debugging.

The race itself is upstream and well-known:
  rust-lang/rust#83994       (exit() not thread-safe)
  rust-rocksdb#270           (can't gracefully close rocksdb)
  facebook/rocksdb#3453      (Env threads outlive DB)

Please go to the `Preview` tab and select the appropriate sub-template:

* [Classic PR](?expand=1&template=default.md)
* [Bump version](?expand=1&template=bump_version.md)

---------

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>