test and fix: seed exception context does not survive being thrown

[cdmren]

Confirming what I suspected but didn't know for sure was a bug in #113. This stuff is subtle. When you throw as SomeException, the context gets lost. I don't totally understand why.

First commit adds a failing test, second fixes it.

AI Slop

First commit: specs to check the concerns raised on this PR about
logFailingSeed's catch-and-rethrow: does the context added by
addExceptionContext survive the throwIO call, and does logFailingSeed
discard context the caught exception already had?

seedPrefixesHUnitFailureSpec is a baseline showing the HUnitFailure
reason-prefixing still works. seedExceptionContextSpec and
seedExceptionContextNonHUnitFailureSpec assert the seed shows up via
someExceptionContext after runGraphulaT rethrows — both fail on that
first commit (expected: [2] but got: []).

The cause turned out to be two layers deep. throwIO's implementation calls
toException on its argument, and base's Exception SomeException
instance explicitly resets context to empty there ("This drops any attached
ExceptionContext"). Since addExceptionContext always returns a
SomeException, throwing that result wipes the context we just attached.
Building an ExceptionWithContext instead (whose toException sets
?exceptionContext directly rather than resetting it) avoids that — but
UnliftIO.Exception.throwIO, which logFailingSeed was using, is
liftIO . EUnsafe.throwIO . toSyncException: toSyncException converts
back to a plain SomeException before handing it to the real
Control.Exception.throwIO, re-triggering the same reset one level down.

Second commit: Graphula.ExceptionContext gains
throwWithGraphulaExceptionContext, which builds the ExceptionWithContext
and throws it via Control.Exception.throwIO directly (bypassing
UnliftIO.Exception's wrapper). All of the base-version-conditional logic,
and the only CPP in this change, lives in that one module; Graphula.hs
calls it unconditionally. All 6 specs pass now.

[pbrisbin]

As far as I can tell, throwIO calls toException (in some form), which (according to its docs) must always build a SomeException with an empty context.

Piecing together the docs, it just seems really hard to get "rethrowing" right. I think the Right Way is to use catchNoPropagate, which gives you ExceptionWithContext e, then call rethrowIO on that (after modifying however we need).

Lastly, our end-users (and so our tests/docs) should be using tryWithContext or just catching @ExceptionWithContext to make the context available on handling.

catchNoPropagate and tryWithContext aren't available until base-4.21 though, so I'm not sure how close we can get to that within base-4.20.

[pbrisbin]

Well, at least Well-Typed agrees this behavior is dumb.

The definition of toException is more problematic, however. Prior to 9.10, calling toException on SomeException was just an identity ... Now, however, the implementation must clear the existing context in order to satisfy the contract... I think this is simply wrong; at the very least, it is highly counter-intuitive, and it also does not match the original proposal; I don’t know why this was changed

https://well-typed.com/blog/2026/05/lay-annotation-land/#caution-instance-for-someexception-itself