design: fork strategy — hard-fork vs track-upstream, kameo commit, license/attribution

[joeldsouzax]

Decide before #1 (the fork):

• Hard-fork (diverge freely, no upstream rebase) vs soft-fork (keep kameo layout, periodically rebase). Given the Zenoh rewrite of src/remote/ + M7 de-handroll, divergence is heavy -> recommend HARD-FORK, but decide explicitly: it dictates whether we preserve kameo file structure for rebaseability.
• Pin the exact kameo commit/tag to fork from (current 0.21.0).
• License + attribution: kameo is MIT/Apache-2.0 — carry upstream LICENSE + attribution into bombay; confirm bombay license (agency=Apache-2.0, nexus=MIT/Apache) and compatibility.
• Repo init: GitHub fork-link vs fresh history import vs squashed import.
  Output: recorded decision (comment here) that chore: fork kameo into bombay + workspace/CI setup #1 executes.

[joeldsouzax]

M0 sequence 2/3 — do after the spike (#62) confirms viability. This decision is the gate into M1: it unblocks #1 (the fork). Can overlap with #64.