Improve AppMerge ergonomics — per-key merge handler registration

[b5119]

Currently merge() is a single method on MigratableApp that dispatches
on _key internally. An app using AppMerge on keys "contacts" and
"bookmarks" must write one function that routes on the key string.

Desired design

Per-key merge handler registration, matching the setMergeHandler sketch
in ADR 0012:

// Kotlin — what the API should feel like
NexusMigrate.register("bookmarks", ConflictPolicy.APP_MERGE) {
    key, local, remote -> mergeBookmarks(local, remote)
}
NexusMigrate.register("contacts", ConflictPolicy.APP_MERGE) {
    key, local, remote -> mergeContacts(local, remote)
}

Why defer to after JNI bindings

The Rust trait API and the JNI/Kotlin bridge should be redesigned
together so the Kotlin-side impact is visible before committing to the
new shape. Reopening the trait without seeing the JNI usage would risk
a second redesign.

References

• ADR 0012 section "Android bindings" — setMergeHandler sketch
• PR Improve AppMerge ergonomics — per-key merge handler registration #34 (feat/migrate-sdk) — the initial trait API this issue proposes
  to improve