Adopt typed throws in FCPKit, FCPKitScripting, and FCPXMLDiff

[leogdion]

Context

FCPKitDSL adopted typed throws in #42/#43/#44 — throws(BuildError) runs end to end from DSLNode.build through Document.export, so callers get a concrete catch type instead of any Error.

That was straightforward because every throw site in FCPKitDSL raises BuildError and nothing else, and the module calls no throwing FCPKit API. The remaining modules are not so tidy.

Scope

Module	Throwing declarations	Error types
FCPKit	47	6 — FCPXMLError, FCPTimeError, AssetClipEditingError, DecodingError, …
FCPKitScripting	21	TBD
FCPXMLDiff	5	TBD

The design decision

FCPKit is the hard one, and it needs a call before any code moves:

1. Per-API typed throws — each function declares the concrete error it actually raises. Most precise, but the public surface gains several error types and some functions genuinely raise more than one.
2. A unifying error enum — wrap the existing types in one FCPKitError and type everything to it. Uniform, but it is an API change for anyone already catching FCPXMLError, and it flattens meaningful distinctions.
3. Partial adoption — type only the APIs with a single obvious error, leave the rest untyped. Least disruptive, least consistent.

DecodingError is a particular wrinkle: it comes from Codable and cannot be narrowed away where decode paths propagate it.

Note on source compatibility

Typed throws narrows a protocol requirement: a conformer declaring plain throws no longer satisfies throws(E). That is a hard compile error, not a warning — confirmed while doing FCPKitDSL. Anywhere a public protocol gains a typed requirement, external conformers break. Worth calling out per-protocol before adopting.