Recover ref/out/in on generic-instance and ref-readonly call sites

[richlander]

What

Recovers call-site ref/out/in keywords that the pipeline was dropping, in two related cases the raising-pass review surfaced.

Generic-instance calls

A call on a constructed generic type resolves as a MemberReference with a TypeSpecification parent, which carries no parameter rows — so out/in were lost and rendered as ref (CS1620/CS1615). The classic case: every Dictionary<,>.TryGetValue(out v) call. This resolves the MemberRef back to its underlying generic MethodDef (signature-blob match within the declaring TypeDef) and reads its parameter rows.

Ref-kind classification / spelling

• ref readonly parameters (RequiresLocationAttribute) now join in (IsReadOnlyAttribute) as readonly references — spelled without a mutable-ref keyword (valid for a readonly/rvalue argument). Previously a ref readonly ctor like ReadOnlySpan<T>(ref readonly T) was rendered ref this on a readonly receiver → CS1605.
• out/ref arguments now require a genuine assignable lvalue; a cast (unbox) is not one, so out (T)x (CS0206) falls back to the default spelling. in still accepts a value.

Validation

Harness defect-diff (--diff-defects) vs main, over the methods checked in both runs:

REGRESSED (method gained the code):
  (none)
IMPROVED (method lost the code):
  CS1620: 2   (MemberInfoCache.PopulateProperties, Attribute.AddAttributesToList)
  CS1605: 1   (GuidResult.ToGuid)

A clean win. Decompiler tests 427 pass (adds a generic-instance out/in call-site test and a RefKindBox<T> fixture).

Dependency

Depends on #608 (compile-check: import internal members) for the clean scoreboard. Without it, four spurious CS1615 appear (Array.Fill/Sort/UnsafeArrayAsSpan, String.JoinCore): the decompiled ref is correct, but it calls the internal Span<T>(ref T, int) ctor that the external compile-check shell can't access, so Roslyn mis-binds and mis-reports. #608 makes those report CS0122 (filtered noise) instead. Merge #608 first.

🤖 Generated with Claude Code