Surface parser error in plcParserOption option parsing

[zeme-wana]

What

The PLC parser error in plcParserOption (in PlutusTx.Options) was captured as _e and discarded — addressing the -- TODO: use the error left at that call site.

The CannotParseValue constructor's third field was a SomeTypeRep, but every one of the three construction sites (plcParserOption, readOption, fromReadOption) passed someTypeRep (Proxy @Int) as a placeholder, regardless of the actual type being parsed. So the rendered message was always:

Cannot parse value "…" for option "…" into type Int

…which is misleading for plcParserOption (the parser isn't necessarily for Int) and offers no detail on why parsing failed.

Change

• Replace the dead SomeTypeRep field of CannotParseValue with a Text detail.
• plcParserOption now threads Text.pack (show e) through — PlutusCore.Error.ParserErrorBundle's Show instance renders via Megaparsec's errorBundlePretty, which produces a human-readable error with source position.
• readOption and fromReadOption pass short honest descriptions ("could not parse value", "expected Int") instead of the bogus Int proxy.
• renderParseError formats the detail inline after : .
• Drop the now-unused Data.Proxy import.

CannotParseValue is only pattern-matched by renderParseError in this same module (verified by codebase-wide search), so the field shape change is safe.

Verification

• cabal build plutus-tx-plugin — clean, no new warnings.
• cabal test plutus-tx-plugin:plutus-tx-plugin-tests — all 841 tests pass.

Checklist

• Self-reviewed the diff
• Useful pull request description
• Changelog fragment added (plutus-tx-plugin/changelog.d/20260512_use_parser_error.md)
• Targeting master
• Reviewer requested

[Unisay]

Well done!

One question on the tests, though. This PR changes the user-visible error text (what people see in GHC logs when an option value is malformed), but the diff doesn't add a single golden file. So there's no recorded "before vs after": if someone later swaps show e for something less informative, CI won't notice.

Patterns for golden tests over error text already exist in the repo:

• testParseErrorGolden at plutus-core/untyped-plutus-core/testlib/Generators/Spec.hs:249-257: captures errorBundlePretty output directly, essentially the same case
• nestedGoldenVsErrorOrThing at plutus-core/plutus-core/test/TypeSynthesis/Spec.hs:65-68: PLC type errors
• goldenTypeFromPir at plutus-core/testlib/PlutusIR/Test.hs:249-261: PIR typecheck errors
• plutus-tx-plugin/test/Plugin/Errors/Spec.hs:39-56: closest in spirit, since these are plugin errors too

A minimal new test could:

1. feed processOptions (or whichever top-level entry point applies) an option with broken PLC, e.g. context-eq with an unbalanced paren;
2. run it through renderParseError;
3. compare against a .golden file with the expected message including source position.

That would also cover readOption and fromReadOption, where the new "could not parse value" and "expected Int" strings currently have no test coverage either.

Not a blocker. Just a bit odd that the whole change is about error text, and there's no error text in the tests.