Fair benchmark: identical inputs, correct counts, tests and CI

[fasharif]

What was wrong

• The comparison was not fair. Each algorithm sorted a different random array, once, at a single size of 1,000.
• The counts were wrong. Insertion sort never counted the comparison that ends its inner loop. "Swaps" meant different things in different algorithms, and included swapping an element with itself.
• Timing was too coarse. It used clock() for a single run of a millisecond-scale task.
• An empty array broke bubble sort. n - 1 underflowed.
• Sorted input could overflow the stack. Quicksort always recursed on both sides, and sorted input is its worst case.
• The claims went beyond the measurements. The README talked about energy, but nothing measures energy.

What changed

• Every algorithm gets an identical copy of each input: sizes 500, 1,000, 2,000 and 4,000, in random, sorted, reversed and nearly sorted order.
• Each run is timed with a monotonic clock, the median of 5 runs is reported, and every result is checked to be sorted.
• Comparisons and array writes are counted the same way in all three algorithms.
• Quicksort recurses into the smaller side, so its stack depth stays O(log n).
• Unit tests check each algorithm against qsort, and check exact counts on sorted and reversed input.
• CI builds with GCC and Clang, runs AddressSanitizer and UBSan, runs the benchmark, and uploads the CSV and charts.
• visualize.py saves charts to files instead of opening windows.
• Adds an MIT licence.

A follow-up commit on this PR rewrites the README with the numbers CI measures.

🤖 Generated with Claude Code