#1053 feat(recordings): move and copy recordings to another project

Why

Basecamp's API can now move or copy a recording to another project, as the web's Move… and Copy… dialogs do (basecamp/bc3#14136). The CLI and the MCP server need this to move and copy cards across projects without a wormhole. This adds the three operations in every SDK.

What changed

• MoveRecording, CopyRecording and GetFiling, with a Filing shape, on the Recordings service. In Go, they are Recordings().Move, Copy and GetFiling.
• No SDK retries either POST. A repeated copy makes another copy. A repeated move answers 422 or 404 instead of the filing, so a retry would turn a move that started into an error.
• bc3's documented examples are fixtures, and each SDK has tests. Every SDK has a test that sends a copy exactly once on a 503.

Scope

• The bc3 pin does not move. Three route-allowlist waivers cite #14136 until the next repin, as #960 did. A repin would bring in six unrelated routes to triage.
• status and type are documented strings, not Smithy enums. A Swift enum would fail to decode a filing if bc3 adds a status.

Blast Radius

This is additive. The only shared files touched are the generator registrations for these three operations and the operation counts.

Verification

• Go, TS, Ruby, Python, Rust, Kotlin, conformance, drift, route-parity, fixture and idempotency checks all pass. Swift generation and drift pass in Docker. The Swift build and tests first run in CI.
• make stops on one lint finding that also fails on main: eventfeed/renew.go:315 G118 with the pinned golangci-lint. CI uses the latest version, which passes.
• The Go wrapper ran against a local bc3 server. A copy and a move of a card completed with new card ids. Repeating the move answered 404.
• An independent GPT-6.1-sol review found nothing to fix.