ADR: decide the git-cas import and compatibility posture

[flyingrobots]

Outcome

Decide whether and how existing git-cas assets can be imported without allowing Git representation details or legacy validation weakness to contaminate Keep's native contracts.

Dependencies

Blocked by #3, #9, #14, and #20.

Decision questions

• Is import required for the first integrated release or explicitly deferred?
• Which git-cas manifest and encryption versions are accepted?
• Is import streaming, staged, and independently verified?
• Must imported content be re-identified under Keep's canonical BlobId?
• How are legacy missing manifest hashes, malformed submanifest topology, and conflicting digest/OID pairs handled?
• Is import one-way, and is on-disk compatibility rejected?
• Which provenance and weaker-evidence posture is retained?

Acceptance criteria

• A numbered ADR chooses import-now, import-later, or no-import with concrete migration evidence.
• Native Keep formats remain independent of Git OIDs, Git trees, refs, and process execution.
• Imported bytes are verified against both available source evidence and Keep's destination identity.
• Missing or weak legacy evidence is represented explicitly and never upgraded silently.
• Malformed chunk order, gaps, overlap, aggregate mismatch, digest conflict, and decryption failure are refused.
• Import interruption and restart behavior is specified.
• Test fixtures are license-safe and contain no real private workspace material.
• The decision does not block the native Golden File Worldline unnecessarily.

Non-goals

• Making Keep a Git implementation.
• Preserving git-cas physical handles as stable Keep identity.
• Bidirectional synchronization.