Fix panic parsing a rockspec comment that ends at EOF

[arpitjain099]

While reading through the Lua cataloger I hit a couple of unchecked byte reads in the hand-written rockspec parser that can panic on malformed input. This tightens the bounds checks so a bad rockspec fails gracefully instead of taking the whole cataloger down.

There are two reads that go one byte past the end of the buffer when a comment runs right up to the end of the file:

• parseRockspecBlock: when a block starts with a leading comment that consumes the rest of the file, the SkipWhitespace right after it leaves the index at len(data), and the following c = data[*i] reads out of range. Added an EOF check that returns the (empty) block cleanly.
• parseComment: data[*i] is read after the index has been advanced, to detect a CR/LF pair. If a lone \r is the last byte, that read is out of bounds. Guarded it with *i < len(data).

You can reproduce both with a rockspec whose last line is a comment ending in a bare carriage return and no trailing newline, for example --\r on its own, or a trailing -- x\r. That's malformed but harmless input. The problem is that the panic aborts the entire Lua cataloger, so a single odd file drops every valid Lua package in that scan rather than just skipping the one file.

I added two table cases to rockspec_parser_test.go covering a comment-only file and a trailing comment, both ending in a bare CR. Before the change they panic with an index-out-of-range; after it they parse without error. go test ./syft/pkg/cataloger/lua/... passes.

This is a robustness fix for malformed lockfiles, not a security report.