bug(cycles): function-level cycle count differs between native and WASM engines

[carlos-alm]

Found during dogfooding v3.3.1

Severity: Low
Command: codegraph cycles --functions

Reproduction

# Build with WASM
codegraph build . --engine wasm
codegraph cycles --functions --json | jq '.cycles | length'
# Returns: 11

# Build with native
codegraph build . --engine native
codegraph cycles --functions --json | jq '.cycles | length'
# Returns: 8

Expected behavior

Both engines should detect the same number of function-level cycles.

Actual behavior

Native engine detects 8 function-level cycles, WASM detects 11. The 3 extra cycles in WASM are likely from slightly different call edge extraction — WASM produces 3986 calls vs native's 4000, but the cycle difference suggests some WASM call edges create small cycles that native resolves differently.

Root cause

Likely related to minor differences in how the WASM and native extractors handle certain call patterns (e.g. recursive helpers, mutually recursive test functions). The node count difference (10857 WASM vs 10883 native) indicates native extracts slightly more symbols, which may break some cycles by resolving calls more precisely.

Suggested fix

Compare the specific cycles found by each engine to identify which call edges differ. May be acceptable as known parity gap if the extra WASM cycles are from test files.

[carlos-alm]

Reopening: PR #602 was reverted — it only documented the gap as "expected behavior" without fixing the root cause. The WASM extraction layer still produces false cycles due to ambiguous call resolution. The fix should be in the extraction/resolution layer, not in documentation.