FirstSet computation uses a naive full-rescan fixed-point instead of a worklist algorithm

[halotukozak]

Found during an algorithmic-complexity / collections audit ahead of 1.0.0.

`src/halotukozak/alpaca/internal/parser/FirstSet.scala:32-36`:

```scala
@tailrec
private def loop(productions: List[Production], firstSet: FirstSet): FirstSet =
val newFirstSet = productions.foldLeft(firstSet)(addImports)
if firstSet == newFirstSet then newFirstSet
else loop(productions, newFirstSet)
```

This is the textbook fixed-point algorithm for computing FIRST sets, but it re-scans every production on every iteration until nothing changes, rather than a worklist that only reprocesses productions whose relevant non-terminal's FIRST set actually changed on the last pass. Correct, but not asymptotically optimal -- worst case is O(iterations × productions) where a worklist version would do meaningfully less redundant work on grammars with many independent non-terminals.

This only affects compile-time (macro-time grammar table construction), not anything a user's program pays at runtime. Not a problem for the grammar sizes exercised by the current test suite/benchmarks, but worth tracking as a known optimization opportunity if large user grammars ever show up as slow to compile -- same theme as #465/#466/#462.

Suggested fix: switch to a worklist-based fixed-point (e.g. seed the worklist with all productions, and after updating a non-terminal's FIRST set, only re-enqueue productions whose RHS starts with that non-terminal).

[halotukozak]

Investigated, deferring rather than implementing now -- this turned out riskier than the issue's framing suggested.

`addImports` decides whether to keep pulling in later RHS symbols based on whether `firstSet(head)` currently (mid-fixpoint) contains `Symbol.Empty` -- so a production's dependency on later symbols in its own RHS is dynamic, not statically knowable up front from the grammar alone. A correct worklist rewrite needs either (a) a separate nullability pre-pass (its own small fixed point, computed once, since NULLABLE(X) genuinely is static) so dependencies become determinable before the FIRST-set loop starts, or (b) very careful dynamic re-derivation of a production's dependency set as nullability facts are discovered mid-loop. Either is a real algorithm change, not a mechanical List→worklist swap.

Also: the existing `FirstSetTest` doesn't cover a production with 2+ sequential nullable non-terminals in its RHS (e.g. `X -> A B c` with both A and B nullable) -- exactly the path a worklist rewrite most needs to get right and the naive version currently gets right "for free" by brute-force re-scanning. Safely landing this would want a differential test (naive vs. worklist agree on many random small grammars) plus that missing case, before touching the algorithm.

Given the issue itself already notes "not a problem for current grammar sizes," and this is a parser-generator correctness algorithm (a silent bug here means silently wrong parse tables, not a crash), I'm not comfortable making this change without that safety net in place. Leaving as a documented, deferred opportunity rather than rewriting now. Same theme as #465/#466/#462 -- happy to revisit if a real grammar shows up that's actually slow to compile because of this.