list_issues legacy snap: restore strict field_filters Required to match main

The legacy variant's field_filters items schema was loosened from
['field_name', 'value'] (main) to ['field_name'] (MS-aware) when I
collapsed the two schemas into the buildListIssues helper. The MS-aware
loosening is correct (either 'value' or 'values' is acceptable, enforced
at runtime in parseRawFieldFilters), but the legacy variant has no
'values' slot so it should keep 'value' required outright.

The runtime parser still rejects missing value in either variant, so
this was a schema-strictness regression rather than a behavioural one,
but worth fixing — the legacy snap is now byte-identical to main's
list_issues.snap, which is the right invariant: legacy variant === main.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: owenniblock

pkg/github/__toolsnaps__/list_issues.snap

@@ -32,7 +32,8 @@
             }
           },
           "required": [
-            "field_name"
+            "field_name",
+            "value"
           ],
           "type": "object"
         },

pkg/github/issues.go

@@ -2485,6 +2485,14 @@ func buildListIssues(t translations.TranslationHelperFunc, multiSelectEnabled bo
 		}
 	}
 
+	// Legacy variant requires `value` outright (its schema has no `values` slot).
+	// MS-aware variant only requires `field_name` because either `value` or
+	// `values` is acceptable; the parser enforces exactly-one-of at runtime.
+	fieldFilterRequired := []string{"field_name", "value"}
+	if multiSelectEnabled {
+		fieldFilterRequired = []string{"field_name"}
+	}
+
 	schema := &jsonschema.Schema{
 		Type: "object",
 		Properties: map[string]*jsonschema.Schema{
@@ -2528,7 +2536,11 @@ func buildListIssues(t translations.TranslationHelperFunc, multiSelectEnabled bo
 				Items: &jsonschema.Schema{
 					Type:       "object",
 					Properties: fieldFilterItemProps,
-					Required:   []string{"field_name"},
+					// Legacy keeps the historical strict shape (field_name + value).
+					// MS-aware loosens to just field_name because either `value` or
+					// `values` is acceptable — the parser enforces "exactly one of"
+					// at runtime.
+					Required: fieldFilterRequired,
 				},
 			},
 		},