JobManagerCrashedError jobs are never retried
Currently, we have 7768 jobs with error_code `JobManagerCrashedError`. Some of them are caused by zombie killer set crashes.

```
Atlas atlas-x5jgb3-shard-0 [primary] datasets_server_cache> db.cachedResponsesBlue.aggregate([{$match:{error_code:"JobManagerCrashedError","details.copied_from_artifact":{$exists:false}}},{$group:{_id:{kind:"$kind"},count:{$sum:1}}},{$sort:{count:-1}}])
[
  { _id: { kind: 'split-duckdb-index' }, count: 3658 },
  { _id: { kind: 'split-descriptive-statistics' }, count: 1872 },
  { _id: { kind: 'config-parquet-and-info' }, count: 1765 },
  { _id: { kind: 'split-first-rows-from-streaming' }, count: 322 },
  { _id: { kind: 'split-first-rows-from-parquet' }, count: 72 },
  { _id: { kind: 'split-opt-in-out-urls-scan' }, count: 60 },
  { _id: { kind: 'dataset-config-names' }, count: 21 }
]

```

But most of them are set as crashed when deploying and are never retried, even if they are fast and straightforward to process.
Should we retry those jobs in backfill?  I think we should differentiate the ones that are easy to process against those that are difficult (primarily because of OOMs), maybe retry once or twice, and set a different error so that we can identify which of them are caused by limited resources.
  

JobManagerCrashedError jobs are never retried: Currently, we have 7768 jobs with error_code `JobManagerCrashedError`. Some of them are caused by zombie killer set crashes.

```
Atlas atlas-x5jgb3-shard-0 [primary] datasets_server_cache> db.cachedResponsesBlue.aggregate([{$match:{error_code:"JobManagerCrashedError","details.copied_from_artifact":{$exists:false}}},{$group:{_id:{kind:"$kind"},count:{$sum:1}}},{$sort:{count:-1}}])
[
  { _id: { kind: 'split-duckdb-index' }, count: 3658 },
  { _id: { kind: 'split-descriptive-statistics' }, count: 1872 },
  { _id: { kind: 'config-parquet-and-info' }, count: 1765 },
  { _id: { kind: 'split-first-rows-from-streaming' }, count: 322 },
  { _id: { kind: 'split-first-rows-from-parquet' }, count: 72 },
  { _id: { kind: 'split-opt-in-out-urls-scan' }, count: 60 },
  { _id: { kind: 'dataset-config-names' }, count: 21 }
]

```

But most of them are set as crashed when deploying and are never retried, even if they are fast and straightforward to process.
Should we retry those jobs in backfill?  I think we should differentiate the ones that are easy to process against those that are difficult (primarily because of OOMs), maybe retry once or twice, and set a different error so that we can identify which of them are caused by limited resources.
  
