recipe: sort the two map iterations whose keys reach the report

Go randomises map order, and two loops in the recipe validator walked a
map to name unknown keys as problems. A recipe with two bad keys in a
contains entry, or two bad keys inside an expectation, could print its
problems in a different order on two runs of the same file.

No file bytes were affected - this is the report, not the output - but
RC7 promises every problem at once, and a list whose order moves between
runs is a poor way to keep that promise. A test asserting on the whole
message would also have been flaky for a reason nobody would find.

Checked all twelve map iterations in product code rather than these two.
Ten already sorted, including the one behind `tfg formats` and the one
behind the closed reason list, and one of them carries a comment saying
why. So the convention was already here and these two were the exception
rather than a decision. They now go through one shared sortedKeys.

Also fixed: the doc comment on Parse had come adrift from Parse when
MaxBytes was added above it, and was documenting the constant instead.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: donislawdev

internal/recipe/recipe.go

@@ -88,7 +88,10 @@ func contentGroups(p *problems, where string, raw []map[string]any) []Content {
 		at := fmt.Sprintf("%s: contains entry %d", where, i+1)
 		g := Content{Count: 1}
 
-		for key := range item {
+		// Sorted, because Go randomises map order and these keys become
+		// problems in the report. Unsorted, the same broken recipe would print
+		// its problems in a different order on two runs.
+		for _, key := range sortedKeys(item) {
 			switch key {
 			case "format", "count", "size":
 			default:
@@ -161,11 +164,6 @@ type Output struct {
 	Manifest string
 }
 
-// Parse reads a recipe and returns it only when every check passes.
-//
-// Nothing is written before this succeeds, and it reports every problem at
-// once rather than the first one. Fixing a recipe one error per run is the
-// cheapest way to make someone stop using the tool.
 // MaxBytes is the largest recipe this build will read.
 //
 // A recipe comes from somebody else's repository - it can arrive in a pull
@@ -195,6 +193,11 @@ func (e *TooLargeError) Error() string {
 		e.Name, e.Bytes, MaxBytes)
 }
 
+// Parse reads a recipe and returns it only when every check passes.
+//
+// Nothing is written before this succeeds, and it reports every problem at
+// once rather than the first one. Fixing a recipe one error per run is the
+// cheapest way to make someone stop using the tool.
 func Parse(src []byte, name string) (*Recipe, error) {
 	// Checked here as well as before the read, because this is the door every
 	// caller comes through - including the fuzz target, which hands over bytes
@@ -561,6 +564,17 @@ var reasons = map[string]bool{
 	"malware_signature": true, "duplicate": true, "none": true,
 }
 
+// sortedKeys is map iteration with the randomness taken out, for the places
+// where the keys become text somebody reads.
+func sortedKeys(m map[string]any) []string {
+	out := make([]string, 0, len(m))
+	for k := range m {
+		out = append(out, k)
+	}
+	sort.Strings(out)
+	return out
+}
+
 func reasonList() string {
 	out := make([]string, 0, len(reasons))
 	for r := range reasons {
@@ -639,7 +653,7 @@ func expectation(p *problems, where string, v any) (string, string) {
 
 		// Any key other than the two we carry would be dropped on the way to
 		// the manifest, and a dropped expectation is one nobody ever checks.
-		for k := range x {
+		for _, k := range sortedKeys(x) {
 			switch k {
 			case "outcome", "reason":
 			default: