repo list/verify: hablan HTTP — un repo remoto con 173 paquetes se leía como vacío

`repo list --repo <url>` tomaba un `PathBuf`, así que trataba la URL como una ruta
relativa que no existe y respondía **«repo vacío» con salida 0**. No es que no
soportara el caso: es que afirmaba lo contrario de lo que pasaba, y con rc=0, que
es la forma de fallo que un script no puede detectar. Salió al probar el repo del
dominio nuevo.

`install --repo` ya sabía hablar HTTP con `RepoSource` (ADR 0014: lista de
orígenes separada por comas, probados en orden). `list` y `verify` ahora usan el
MISMO resolvedor, así que la misma cadena de espejos vale en los tres verbos.
`sign` se queda local a propósito: firmar es escribir.

Y `verify` remoto no es un extra — es el caso de uso del ADR 0014. Verificar el
release de un espejo ANTES de instalarle nada era imposible sin construir.

De paso, tres estados que se daban por iguales y ahora se distinguen (CLAUDE.md
§3: un ausente falla ruidosamente, un vacío llega hasta el final diciendo que todo
fue bien):

  dir que NO EXISTE        → error, rc=1, y sugiere que quizá era una URL
  dir sin index.json       → «repo por crear» (estado válido: lo crea `pack --repo`)
  índice con 0 paquetes    → «índice publicado y SIN paquetes»
  origen que no sirve      → error del fetch, con los orígenes probados

Y el índice se atribuye al origen que REALMENTE lo sirvió, no a la lista entera:
con `<espejo-caído>,<bueno>` la salida dice el bueno. Es la misma regla que el
propio `fetch_desde_algun_origen` aplica a los `.swm` —«decir bajado de la lista
entera cuando sólo uno respondió es una media verdad»— que `read_index` tiraba.

Medido contra el repo vivo: `list` 173 paquetes [release firmado por release],
`verify` trusted. 93+93+6+1+3+4 tests del crate en verde.

docs/06-swm-format.md

@@ -147,10 +147,17 @@ CLI:
   `.swm`; con URL baja el índice + el cierre de deps a un temporal y procede igual).
   `--prefix`/`--skip-source-patch` para staging y dry-run de schema. `--require-signed` exige que
   el release esté firmado por una clave confiada (modo estricto: no basta con reproducir).
-- `takana repo list [--repo DIR]` — lista el catálogo (`<repo>/index.json`).
+- `takana repo list [--repo DIR|URL]` — lista el catálogo (`<repo>/index.json`). Desde el
+  2026-09-21 acepta lo MISMO que `install --repo`: un directorio o una lista de orígenes HTTP(S)
+  separada por comas. Antes sólo miraba directorios y ante una URL respondía **«vacío» con salida
+  0** — un repo remoto con 173 paquetes se leía como uno sin nada. Y ahora distingue «todavía no
+  hay `index.json`» (repo por crear) de «índice publicado y sin paquetes», que también se daban
+  por iguales.
 - `takana repo sign --repo DIR --key KEY` — firma el ÍNDICE entero (release). Re-firmá tras
-  publicar (cada `pack --repo` invalida la firma del release).
-- `takana repo verify --repo DIR [--trust DIR]` — verifica la firma del release.
+  publicar (cada `pack --repo` invalida la firma del release). **Sólo local:** firmar es escribir.
+- `takana repo verify --repo DIR|URL [--trust DIR]` — verifica la firma del release. También
+  acepta orígenes HTTP(S): verificar el release de un espejo ANTES de instarle nada es justo el
+  caso de uso del ADR 0014, y hasta el 2026-09-21 no había forma de hacerlo sin construir.
 - `takana uninstall <nombre> [--db FILE]` — borra los ficheros que el paquete registró (refcount:
   respeta los que otro paquete instalado también aporta) y lo quita de la DB de instalados.
 - `takana installed [--db FILE]` — lista los paquetes instalados. `install` registra cada paquete