Opt-in strict union parsing

[Szer]

DiscriminatedUnionConverter.resolveObject falls back to shape-based overlap scoring whenever a discriminator value doesn't match any declared case, and Array.maxBy silently picks the first declared case. Its payload is then deserialized from JSON that's missing the case's real fields, leaving them null even though F# records/DUs are non-nullable by declaration. Real example: Telegram Bot API 10.3 added RichBlockButtons, but RichBlock has no Buttons case, so

{"type":"buttons","buttons":[{"text":"GET MORE","style":"success","url":"https://example.com"}],"align":"center"}

silently deserializes as RichBlock.Paragraph with Text = null, which NREs downstream. This PR adds an opt-in strict mode that fails loudly instead.

• Level 1 - unknown discriminator fails: when the JSON carries an [<Always>] discriminator value that matches no case, strict mode raises JsonException instead of scoring. Shape-based scoring is untouched and still used for DUs that have no discriminator at all, and non-strict mode is byte-for-byte unchanged.
• Level 2 - required fields validated: after a case is deserialized, strict mode checks that every public, non-option, reference-typed property of the payload record is non-null, raising JsonException naming the missing field and case if not.
• Funogram.Tools.strictOptions: a new JsonSerializerOptions sitting next to the existing options, built from the same converters with the strict flag flipped on. Nested unions inherit it automatically since they resolve converters through the same JsonSerializerOptions.
• Not validated: nested records inside a case's payload (out of scope for this PR).
• Default (non-strict) behaviour is unchanged.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EMiBp5SyqwpeiZSYDSn7xZ

[ForNeVeR]

Note that the whole bot infrastructure (Funogram.Tools.parseJsonStream) will still use the old options object. Are we ok with that?

[Szer]

Note that the whole bot infrastructure (Funogram.Tools.parseJsonStream) will still use the old options object. Are we ok with that?

that's a backward compatible change, hence old options object behaves exactly as before.
Some bots are okay with "best effort parsing" mode, some don't. If a change can be a non-breaking one, why not?