feat: add asciicast v2 output format

[veeceey]

Adds support for generating .cast (asciicast v2) files as an output format, so you can do:

Output demo.cast

This has been a requested feature since the early days (#109) - being able to export recordings as asciicast means you can use them with asciinema players, convert to SVG with svg-term-cli, or generate GIFs with agg.

How it works

• Added Asciicast field to VideoOutputs so .cast is a first-class output alongside GIF/MP4/WebM
• During recording, terminal buffer snapshots are captured each frame (only when .cast output is requested to avoid overhead)
• At render time, GenerateAsciicast writes the asciicast v2 JSON Lines format: a header line with version/width/height/timestamp, followed by "o" (output) events with deduplicated content

Testing

$ go test ./...
ok      github.com/charmbracelet/vhs    4.806s
ok      github.com/charmbracelet/vhs/lexer      5.044s
ok      github.com/charmbracelet/vhs/parser      5.272s
ok      github.com/charmbracelet/vhs/token      5.482s

Closes #109

[veeceey]

Test Results

$ go build ./...
# no errors

$ go test ./...
ok      github.com/charmbracelet/vhs    4.806s
ok      github.com/charmbracelet/vhs/lexer      5.044s
ok      github.com/charmbracelet/vhs/parser      5.272s
ok      github.com/charmbracelet/vhs/token      5.482s

All existing tests pass with the new code.

[moritzdietz]

Great PR and indeed something a log of people were longing for!

No snark, but may I ask why you chose to implement v2 instead of v3 of the asciicast file format?
See https://blog.asciinema.org/post/three-point-o/

[veeceey]

Good question! I went with v2 for a practical reason: it has the widest ecosystem support right now. Most of the popular tools that consume asciicast files — asciinema-player, svg-term, agg, and others — have mature, battle-tested v2 support. The v3 format was introduced with asciinema 3.0 and while it does bring improvements (like the header changes and new event types), tooling support for v3 is still catching up. If I had implemented v3, the output files would not be usable with the majority of existing tools people are already relying on.

That said, adding v3 support down the line would be a natural follow-up once the broader ecosystem has adopted it more widely. The internal structure here is straightforward enough that supporting v3 later should be pretty painless.

[drupol]

There's already a PR about this in #706, it would be nice to collaborate to avoid potential frustrations.