#329 check-type :COUNT not (or null integer) in uiop slurp-stream-lines during ocicl-runtime CSV read

Pre-existing (NOT related to the ADR-0032 A2 linkage work — reproduces flag-off). Non-fatal: asdf loads, (asdf:load-system "alexandria") works, alexandria:iota -> (0 1 2 3). Surfaces as noisy ; Error: check-type failed: :COUNT is not of type (OR NULL INTEGER) | in: WHEN during build/funcl boot (the ocicl-runtime auto-load / CSV read path), NOT during a plain (load "asdf.lisp").

Located

asdf.lisp:4365 / :4393 — (check-type count (or null integer)) inside uiop slurp-stream-lines / slurp-stream-forms. count arrives as the KEYWORD :COUNT instead of an integer/nil. Call sites: asdf.lisp:4383/4413/4439 ((slurp-stream-lines input :count (access-at-count at)), (slurp-stream-forms input :count count) + (remove-plist-key :count keys)).

What I ruled out (all WORK in isolation)

• plain (defun f (x &key count) count) called :count 5 -> 5
• &rest opts &key count -> 7
• apply + &rest keys -> 5
• apply + &rest keys &key count prepending :count count (duplicate :count) -> 9

So it is NOT basic &key / apply / duplicate-key handling. It is a subtler interaction in the ocicl-runtime CSV read path (READ-SYSTEMS-CSV -> slurp-stream-lines). Needs tracing: gdb break on the check-type raise, or instrument slurp-stream-lines to print count + the actual arg list at the failing call.

Hypothesis

count is bound to the keyword :count — likely an apply/&rest arg-list construction in the ocicl path that yields ... :count :count ... or a &key default/plist mismatch specific to how ocicl-runtime calls it. The value being exactly :COUNT (the key name) is the tell.