A method written (opts)->(m,n)-> with a return type is silently not installed

Nobody has claimed this yet.

This issue was triaged from [`bugs/dan/0-methods-with-options`](https://github.com/Macaulay2/M2/blob/388c1ff0ce30d83751dea7bc7eac77fdc1305dd7/bugs/dan/0-methods-with-options), one of the 857 files removed from the pre-GitHub `bugs/` tree by [`d2c8d27826`](https://github.com/Macaulay2/M2/commit/d2c8d27826) and catalogued in [#36](https://github.com/Macaulay2/M2/issues/36). **The commentary below was written by Claude (Claude Opus 5, via Claude Code)**, not by @d-torrance, whose account posted it -- please weigh it accordingly.

### The original file, verbatim

```text

i1 : g = method(Options => {});

i2 : g (ZZ, ZZ) := List => (opts) -> (m, n) -> foo

o2 = List => {*Function[stdio:2:29-2:42]*}

o2 : Option

i3 : g (QQ, QQ) := (opts) -> (m, n) -> foo
stdio:3:12:(3):[0]: error: expected method for binary operator to be a function of 2 variables

i4 : methods g

o4 = {}

o4 : VerticalList

Internally, the difference between (opts)->(...) and opts->(...) is that the
former insists on the number of arguments being 1, and the latter doesn't.

So, our sanity checking code, which takes a function and plugs it in as a
method function, detects that, notices the discrepancy between 1 and 2 (the
number of arguments needed), and signals an error. In line 2 above and in your
case, where you (redundantly) give a typical return value type of List, the
error message gets ignored, sigh. In line 3, the error message survives, and
we see what the trouble is.

So, our sanity checking code has to be taught that method functions with
options are not the same as method functions without options. Meanwhile, write
opts instead of (opts).
```

### Where it stands today

Still reproduces, and the failure is silent, which is the part worth fixing:

```m2
i1 : g = method(Options => {});
i2 : g (ZZ, ZZ) := List => (opts) -> (m, n) -> foo
o2 = List => {*Function[...]*}
o2 : Option

i3 : methods g
o3 = {} -- nothing was installed
```

With the return type omitted, the same line is rejected outright:

```m2
i4 : g (QQ, QQ) := (opts) -> (m, n) -> foo
stdio:4:12:(3): error: expected method for binary operator to be a function of 2 variables
```

So supplying a `List =>` return type turns a diagnosed error into a no-op.

### The mechanism, from the file

`(opts) -> (...)` insists on exactly one argument, while `opts -> (...)` does not — the parenthesized
form is a one-argument function whose body happens to be another function. The sanity check that
catches this for the untyped case is bypassed when the value is an `Option`, because what is being
assigned is then `List => f` rather than `f`, and the arity of `f` is never examined.

### Related

**#2864** is a different confusion in the same area (options and method installation), so the two are
worth reading together while touching this code.

_{`open` · disposition `issue` · source of truth: [`bug-triage/catalog.tsv`](https://github.com/d-torrance/M2/blob/bug-triage/bug-triage/catalog.tsv)}

Reproduce the examples from bugs/dan/0-methods-with-options, comparing the (opts) and opts forms and the effect of the List => return type. Trace the method-installation sanity check and the method and methods entry points; read related issue #2864 for context. Done means the invalid form is diagnosed instead of silently leaving methods g uninstalled.

Written by the indexing model from the issue text.