docs(research): POC-1 complete — pkt-line over alkcall BiStream verified

Full V2 fetch handshake (ls-refs + fetch with done + sideband pack) runs
between real git 2.43 and a Rust listener over the alkcall
Connection -> BiStream -> tokio-util compat -> gix-packetline path.

Verification: git ls-remote, git clone (fsck --strict clean), incremental
git fetch, annotated-tag checkout, in-process duplex selftest. All over
alkcall 0.8 core types; the flagged futures-io risk resolved with a
two-line tokio-util compat adapter.

Findings: docs/research/poc-1-findings.md (deliverable; POC source stays
disposable at /workspace/alkgit-poc1 per the standalone POC mode).

Also records in the research docs:
- git-protocol.md: observed done-path shape (no acknowledgments section),
  git:// first-request framing, advertise-once rule
- gitoxide.md: gix-packetline async stop-delimiter + reset() contract
- alk-stack.md: POC-1 verification item marked resolved
- pocs.md: POC-1 status -> proceed

docs/research/gitoxide.md

@@ -70,6 +70,15 @@ compile-time-rejected invariant, so the config can't drift silently.
 - `gix-packetline` — pkt-line encode/decode, both blocking and `futures-io`
   async (`async-io` feature). This is the one crate both the http and ssh
   interfaces need most; it is small and stable (0.22.x).
+  **API contract notes (POC-1, validated live):** `async_io` codec is built
+  on `futures_io` traits — bridging a tokio stream takes
+  `tokio::io::split` + `tokio_util::compat::{compat, compat_write}` (two
+  one-liners). `StreamingPeekableIter` treats `Flush` as a stop-delimiter:
+  on flush, `read_line()` returns `None` (no line is yielded) and the
+  iterator is inert until `.reset()` — a command loop must reset after
+  every request or the next command is silently swallowed. Return type is
+  `Option<io::Result<Result<PacketLineRef, decode::Error>>>` (three layers;
+  wrap it in a session type).
 - `gix-transport` — defines `Protocol` (V0/V1/V2), `client::MessageKind`, and
   the fetch-side abstractions. Only the *types* are reusable server-side;
   its transport implementations (client) are not what we need.