Classify a run's failures, and know when not to retry

Constraints

1. 1Return by_class, counts, unclassified_types, retry_share and should_retry.
2. 2Group by exception type, then map each type to the first class in the policy (taken in sorted class order) that lists it.
3. 3A type no class lists goes to unclassified and is named in unclassified_types.
4. 4A failure with no type at all becomes the type unknown, which is then unclassified like any other.
5. 5retry_share is retryable failures over all failures, rounded to 4 places, and 0.0 when there are none.
6. 6should_retry is true only when there is at least one failure, no fatal ones, nothing unclassified, and every failure is retryable.
7. 7Everything is sorted so two runs advise identically.

Worked example

Four failures arrive: two TimeoutError, one ValueError and one NewThing the policy has never seen. Half the failures are retryable, so a share-based rule would happily advise a retry. should_retry is false, because NewThing is unclassified — and an unknown failure might be a duplicate write, a partial commit or a corrupted file. The conservative answer is the correct one, and naming the unknown type is what turns the block into an action rather than a refusal.

What this tests

That a taxonomy has to make its own gaps visible, and that an automated decision built on it must fail closed. A classifier that silently buckets what it does not recognise is worse than no classifier, because it is trusted.