[ffumero2003]

Context

blazer could upload a large file only through the streaming Writer (local bytes), and b2_copy_part was wrapped nowhere — so it could not compose a large file from mixed sources. large.compose_mixed read no on the parity card.

Changes

• base.LargeFile.CopyPart wraps b2_copy_part (POST .../b2_copy_part, body {sourceFileId, largeFileId, partNumber, range?}), recording the part sha1/size under the large file's lock — reusing the existing FinishLargeFile assembly untouched.
• New CopyPartRequest/CopyPartResponse in internal/b2types.
• copyPart plumbed through both large-file interfaces (incl. the retry wrapper).
• Public b2.Bucket.Compose(ctx, name, parts ...ComposePart) building a large file from an ordered mix of uploaded parts (PartFromReader) and server-side copied ranges (PartFromCopy); validates the B2 part rules (≥2 parts, every part except the last ≥5 MB) and cancels the large file on error.
• A nilable SSE slot is reserved on CopyPart but not marshaled (SSE-C is not on main).

Stored-part/resume seeding is intentionally out of scope (that is Writer.Resume).

Verification

• go build ./... — clean.
• go test ./base/... ./b2/... ./internal/... -race — green, incl. a b2_copy_part body test and compose wire tests (mixed / copy-only / upload-only, validation table, error-cancels-large-file).
• golangci-lint run --new-from-rev=origin/main ./... — 0 issues.
• Repo-owned conformance large.compose_mixed @simulator — PASS.
• Real-B2 demo (blazer-go-demo compose): a 5,000,000-byte uploaded part + a server-side copied range compose to the expected 5,000,007-byte file — PASS.

Merge order

This branch is cut from current main, where startLargeFile takes 6 args. SSE-B2 (#125) adds a 7th *uploadEncryption arg to startLargeFile. If #125 merges first, rebase this branch and add , nil to the Compose call site (one line); otherwise merge this before #125.

Closes #128