fetch git nodes over https

ssh:// cannot authenticate under dora-cli 1.0.1: it fetches through libgit2
with no credential callback, so the only transport that can work is anonymous
https. The documented URLs move accordingly, and the repository is now
dora-image-view rather than dora-plot.

The note about what a `git:` node needs is corrected while here. The cause is
not that a repository is private but that the fetch is anonymous: on Gitea a
repository inside a private organization is internal and answers an anonymous
clone with 401 even when the repository itself is marked public. The
organization has to be public too.

README.md

@@ -14,7 +14,7 @@ Add to your dataflow:
 ```yaml
 nodes:
   - id: view
-    git: ssh://git@gitea.liria.cl:5001/liria/dora-image-view.git
+    git: https://gitea.liria.cl/liria/dora-image-view.git
     tag: v0.1.0
     build: uv pip install .
     path: dora-image-view
@@ -85,11 +85,12 @@ else, and `dora validate --strict` warns about every *typed* input this node dec
 that a dataflow leaves unwired. The strictness belongs to `dataflow.yml`, which drives
 all of them.
 
-**Known limitation (dora-cli 1.0.1).** A `git:` node pointing at a private repository
-does not build: over `ssh://` on a non-standard port the connection fails, and over
-`https://` libgit2 reports `remote authentication required but no callback set`. The
-dataflow validates and the wiring is the form a consumer should use, but running it
-needs that fixed or the repository made public.
+**A `git:` node needs anonymous read access.** dora-cli 1.0.1 fetches through libgit2
+with no credential callback, so a repository that asks for credentials fails with
+`remote authentication required but no callback set`, and `ssh://` cannot authenticate
+at all. Note that marking a repository public is not sufficient on Gitea: a repository
+inside a **private organization** is treated as internal and still answers anonymous
+clones with `401`. The organization has to be public too.
 
 ### Node manifest