Turn a plain-English function spec into fully type-hinted Python

You are implementing a single Python function against a strict specification, not sketching a rough first draft. Treat this the way a senior reviewer would: nothing ships without full type hints, a real docstring, and explicit handling for every edge case named below — and for any edge case you notice that isn't named but would break this function in the calling context described.

SPEC
Given a list of shipment dicts (each with "weight_kg" and "destination_country"), return the total customs duty owed in USD, using a duty-rate table keyed by ISO country code.

TARGET ENVIRONMENT
Python 3.12+. Dependencies allowed beyond the standard library: stdlib only, no third-party packages. Do not import anything outside that list, and do not assume a package is available just because it is common — if you genuinely need something not listed, say so and explain why the standard library alone can't do the job.

CALLING CONTEXT
Called once per warehouse batch job, batch size up to 5,000 shipments — must not raise on a single bad record and abort the whole batch.

REQUIREMENTS
1. Full type hints on every parameter, the return type, and any local variable whose type isn't immediately obvious from its assignment. No bare Any anywhere — if you truly can't narrow a type further, say so in an inline comment naming why.
2. A docstring in Google or NumPy style: one-line summary, then Args, Returns, and Raises sections listing every exception the function can actually raise, not a generic "may raise an exception."
3. Explicit, named handling for: empty shipment list, a shipment missing "weight_kg", a destination_country not present in the duty-rate table, a negative weight. Each one needs a specific, intentional outcome — a specific return value or a specific raised exception type — never a silent fallthrough to whatever the last line of the function happens to do.
4. If you notice an edge case not in empty shipment list, a shipment missing "weight_kg", a destination_country not present in the duty-rate table, a negative weight that would break this function given the calling context above, name it and handle it anyway. Don't treat the given list as the ceiling of what you're responsible for.
5. No print() calls anywhere for control flow, debugging, or status reporting — use the logging module at an appropriate level if the function needs to report anything during execution.
6. Prefer a typed dataclass or NamedTuple over a bare tuple or dict when the function returns more than one related value, so callers get named fields and type-checker support instead of guessing at positional order.

OUTPUT FORMAT
1. The function, fully typed and documented, plus any small supporting type (a dataclass, an Enum, a TypedDict) it needs.
2. A table: each edge case from empty shipment list, a shipment missing "weight_kg", a destination_country not present in the duty-rate table, a negative weight plus anything you added, what triggers it, and exactly what the function does in that case.
3. Two runnable call examples: one on the happy path with a realistic input, and one that deliberately triggers a handled failure, showing what's raised or returned.