pair_connectivity cannot forward optimization/priority, and compute_sync masks all compute errors as "metric not supported"

[Ramdam17]

Two problems in the hypyp.analyses ↔ hypyp.sync bridge.

1. The entire backend system is unreachable from the high-level API.

pair_connectivity (hypyp/analyses.py:345-347) has no optimization or priority parameter, and calls compute_sync positionally (hypyp/analyses.py:436):

result = compute_sync(values, mode, epochs_average)

So every caller of pair_connectivity is hardwired to optimization=None (numpy). That is the function the tutorials and tests/test_stats.py actually use. Across the whole repository there is no non-test call site that sets optimization at all — the only notebook touching compute_sync (tutorial/getting_started.ipynb:880) does not pass it. All of the numba/torch/Metal/CUDA work in #264 is effectively inaccessible to a user following the documented workflow.

Related: there is no docs/API/sync.md, mkdocs.yml has no nav entry for it, and hypyp/sync/README.md is not pulled in by any mkdocs include plugin — so the optimization/priority contract is absent from the published documentation entirely.

2. compute_sync swallows every ValueError raised during computation.

hypyp/analyses.py:550-554:

try:
    metric = get_metric(mode_normalized, optimization=optimization, priority=priority)
    con = metric.compute(complex_signal, n_samp, transpose_axes)
except ValueError:
    raise ValueError(f'Metric type "{mode}" not supported.')

The try wraps metric.compute as well as get_metric. Measured:

  compute_sync(sig, 'plv', optimization='metl')
  -> ValueError: Metric type "plv" not supported.

The real cause is an unknown optimization value (raised at hypyp/sync/base.py:383-386), and the message blames the mode. Worse, any ValueError raised inside a kernel — a shape mismatch, a failed GPU reshape, a broadcast error — is reported as "metric not supported", masking real numerical failures across the whole compute layer.

Suggested fix: scope the try to get_metric only, and use raise ... from None (or better, let the original error propagate — its message is already more informative). Add optimization and priority parameters to pair_connectivity and forward them. Add a docs/API/sync.md page.