Record that in-parameters and AggressiveInlining were measured and rejected #57

Band: documentation, and it exists to stop work rather than to start it

Two micro-optimisations look obviously available in a struct-based library like this one, and neither appears anywhere in src/:

• in Result<T> parameters on the extension methods, so the 32 to 48 byte struct is not copied per call
• [MethodImpl(MethodImplOptions.AggressiveInlining)] on the composition methods

I implemented both and measured them: 30,000,000 two-step chains (Success then Map then Match), best of five runs, Release, net8.0, Apple M1.

Both are marginally slower, and neither difference is outside run-to-run noise. The JIT already inlines methods this small, and already enregisters a struct this size, so the hint adds nothing and in adds an indirection the JIT then has to remove again.

The core is at the floor. 2.3 nanoseconds for a two-step composed chain, zero bytes, and no garbage collection at any generation under sustained eight-thread load. There is no micro-optimisation left in the core worth a release.

Filing this so the next person who has the same idea, which is a reasonable idea, finds the measurement instead of spending a weekend on it. It belongs in docs/ under design decisions when the documentation reorganisation happens, alongside "why readonly struct".

Everything that is left is elsewhere: the async allocation gap, Error.ToString at 1,544 bytes when an exception is attached, and the pooled error path. All three have their own issues.