Happy-generated code fails with `Internal Happy error` with `-XStrictData`

I am new to Happy and want to use it for an (old school) introductory course on compiler engineering. Because I repetitively got the very uninformative `Internal Happy error` error, I tested my whole setup with a minimal example. Surprisingly, it still fails with `Internal Happy error`.

Here is my setup:

```
module Main where

import Token
import Parser

main :: IO ()
main = do
result <- parse [ VAR ]
print result -- should print 0
return ()
```

```
module Token where

data Token = VAR deriving (Show, Eq)
```

```
{
module Parser where

import System.IO
import Token
}

%name parse
%tokentype { Token }
%error { parseError }
%monad { IO } { >>= } { return }

%token
VAR { VAR }

%%

program : VAR { 0 }

{
parseError :: [Token] -> IO a
parseError _ = fail "something went wrong" -- I never see this error message ...
}
```

After diving a bit into the code I saw that `parse` invokes `happyParse start_state = happyNewToken start_state notHappyAtAll notHappyAtAll` with `start_state = 0#`. It seems like that somewhere deep inside the machinery the second `notHappyAtAll` is actually evaluated by Haskell, since it is accessed as a `HappyStk` here:

```
happyFail explist 0# tk old_st _ stk@(x `HappyStk` _) =
let i = (case Happy_GHC_Exts.unsafeCoerce# x of { (Happy_GHC_Exts.I# (i)) -> i }) in
-- trace "failing" $
happyError_ explist i tk
```

As far as I understand, this means that Happy fails with an empty stack - probably right before even reading the first token.

Here is some information about my environment:
- Late 2023 Mac with the `M3` apple silicon
- `ghc --version` prints `9.4.8`
- `cabal --version` prints `3.10.2.1`
- `happy --version` prints `1.20.1.1`

My `build.cabal`:
```
cabal-version: 3.0
build-type: Simple

...

executable HopefullyHappySoon:
hs-source-dirs: src
main-is: Main.hs
other-modules: Token,
Parser
build-depends: base ^>= 4.17.2.1,
array >= 0.5.4.0
build-tool-depends: happy:happy >= 1.20.1.1 -- Just to be sure ...
default-language: GHC2021
```

I appreciate any kind of help in this situation. This issue is also related to #241.