Faster in-place protobuf decode + codegen stale-cache fix

[excpt]

Three related commits, intended for rebase-merge so each lands on main independently.

1. Fix codegen stale-cache trap (#36)

FSharpGrpc_GenerateProto declared Inputs="@(Protobuf)" but not the codegen tool DLL, so a rebuilt generator with unchanged .proto files never re-ran — downstream projects silently compiled stale obj/protos/*.generated.fs.

• Add $(_FSharpGrpc_CodegenDll) to the target Inputs so a rebuilt/upgraded generator invalidates the cached manifest.
• Add _FSharpGrpc_ForceCodegen pre-target: -p:FSharpGrpc_ForceCodegen=true deletes the manifest to force unconditional regeneration.

This is the trap that made the original #18/#35 benchmark un-measurable — the "AFTER" run compiled cached "BEFORE" code.

2. Decode sub-messages in place (#18)

The decoder copied every nested message, packed field, and map entry into a fresh ByteString + second CodedInputStream (input.ReadBytes().CreateCodedInput()) — one byte[] + stream allocation per sub-message, the dominant decode cost on message-heavy payloads.

PushLimit/PopLimit are internal in Google.Protobuf, and our records aren't IMessage (that would need a MessageDescriptor — runtime machinery this codegen avoids). So bound the field loop by the public CodedInputStream.Position instead:

decodeFrom (input) (endPos: int64) =
    while input.Position < endPos do
        match GetTagFieldNumber(input.ReadTag()) with ...

// nested: no copy, no second stream
let endPos = int64 (input.ReadLength()) + input.Position
Address.decodeFrom input endPos

WKT/wrapper fields use the public input.ReadMessage (they are IMessage). list/option surface types are unchanged. decodeFrom gains an endPos parameter (top-level decode passes the buffer length); hand-written generated code in the test projects and all snapshots updated to match.

3. Benchmark + README

Add HighCardinalityUserProfileBenchmarks (the case that stresses sub-message decode) and refresh README numbers from a confirmed-fresh Release run.

Results (F# decode, before → after)

Case	Allocated	Mean
UserProfile, high cardinality (1000 ints + 100 msgs)	109.27 KB → 82.3 KB (−24.7%)	15.8 µs → 12.7 µs (−19.6%)
UserProfile, small (5 ints + 2 msgs)	5,200 B → 2,752 B (−47%)	815 ns → 546 ns (−33%)

The win comes from the decoder implementation alone — list/option kept as-is. The residual F#-vs-C# gap at high cardinality is now almost entirely the list cons cells + option boxing (the immutability surface), which would only close with a breaking list → array change — deliberately deferred.

Tests

146/146 pass, including the 61 cross-language byte-exact (F#↔C#) and 10 gRPC interop tests that prove the new reader is wire-identical. F# formatting and C# formatting clean.

🤖 Generated with Claude Code