fix: fail instead of throw when a transform on a completed FastFuture throws

[pjfanning]

Motivation

FastFuture.successful / FastFuture.failed return already completed futures that override Future.transform to apply the function directly instead of scheduling it. Unlike DefaultPromise, that override did not catch exceptions thrown by the function, so the standard filter, collect and transform combinators on such a future threw synchronously at the call site instead of returning a failed future:

== Future.successful ==      filter/collect/transform with throwing f -> Failure(boom)
== FastFuture.successful ==  filter/collect/transform with throwing f -> thrown synchronously

Callers cannot tell a FastFuture-produced Future from any other, and pekko-grpc now returns them from its public APIs (apache/pekko-grpc#686, apache/pekko-grpc#863), so user code combining those futures hit the difference. map was unaffected because Try.map already catches.

Modification

Route the transform overrides of FulfilledFuture and ErrorFuture through a private helper that converts a NonFatal exception thrown by the function into an ErrorFuture, matching the contract of Future.transform. Both classes are private, so no binary shape changes.

Result

Standard combinators on a completed FastFuture return a failed future when their function throws, the same as for Future.successful / Future.failed.

Tests

• sbt "http-core/Test/testOnly org.apache.pekko.http.scaladsl.util.FastFutureSpec" - the new transform/filter/collect cases fail without the fix (4 failures), 32/32 pass with it
• sbt "http-core/mimaReportBinaryIssues" - no issues (compared against 1.0.0)
• scalafmt --mode diff-ref=upstream/main
• git diff --check

References

None - found while reviewing FastFuture stack and exception semantics for pekko-grpc's increased use of it