feat(b2): add a replication setup helper

[ffumero2003]

Context

blazer can set a raw replication configuration on a bucket (via Bucket.Update) but
has no helper that provisions the correctly-scoped source/destination keys and wires
up the two-sided setup in one call. Every peer tool ships one (TypeScript
addReplicationRule, Python ReplicationSetupHelper, CLI ReplicationSetup).

What it enables

One-call, one-direction replication setup between two buckets: mint correctly scoped
source/destination keys, wire the key mapping and the rule, and leave existing
rules/mappings intact.

Changes

• b2/replication.go — a lean, idiomatic helper (not a stateful wizard), in package
  b2:
  • SetupReplication(ctx, src, dst *Bucket, opts ...ReplicationOption) error — mints
    a destination key (write capabilities) and, for a source with no replication yet, a
    source key (read capabilities); reuses the source bucket's existing
    SourceApplicationKeyID when it already replicates elsewhere (that key is
    bucket-wide — replacing it would break existing destinations); merges the key
    mapping into the destination and appends the rule to the source (auto priority and
    name, honoring prefix / include-existing-files options) without clobbering existing
    rules or mappings.
  • ReplicationStatus(ctx, src *Bucket) ([]ReplicationRuleStatus, error) — a
    config-level reader of the configured rules (no per-file scan).
  • Functional options: WithRuleName, WithRulePriority, WithFileNamePrefix,
    WithIncludeExistingFiles.
• b2/replication_setup_test.go — unit tests for priority computation,
  merge-don't-clobber, the two-bucket update payloads, and source-key reuse.
• .sdkharness/tests/conformance/bucket.replication_helper (+ tests.tsv row,
  contract-count bump) — the repo-owned conformance scenario.

Design notes

Built entirely on the existing main surface (CreateKey + Bucket.Update +
Attrs); no dependency on the create-time replication-config change. The helper is a
single function by design — blazer stays a primitive-exposing library, and orchestration
beyond this (per-file monitoring, key reuse/cleanup, cross-profile setup, pause/unpause)
is intentionally left out of v1.

Verification

• go build ./... — clean.
• go test ./b2/... -race -count=1 — green (incl. the source-key-reuse regression test).
• golangci-lint run --new-from-rev=origin/main ./... — 0 issues.
• Conformance bucket.replication_helper @simulator — PASS (two-sided setup + config
  readback; re-run does not duplicate).
• Real-B2 validation — setup + readback, idempotent re-run, and a multi-destination
  case proving the source key is reused (not replaced) with auto-incrementing rule
  priority, all green.

Closes #136