record that the webcam example is verified, and pin v0.1.1

The example carried a caveat saying it validated but could not be run, because
a `git:` node could not be fetched. The organization is public now, so it can:
dora clones dora-webcam at the pinned tag, builds both nodes, and runs them
against a real camera to a clean exit.

The pin moves to v0.1.1, whose documentation shows the https URL. v0.1.0 points
at an ssh:// URL that dora cannot authenticate, so anyone copying the wiring out
of that tag would have hit the failure this example exists to demonstrate the
absence of.

What a `git:` node does require is still recorded, since it is not obvious:
anonymous read, which on Gitea means a public organization and not merely a
public repository.

dataflow_webcam.yml

@@ -5,10 +5,11 @@
 # dataflow.yml is the gate, and needs neither.
 #
 # This needs anonymous read access to the camera's repository. dora-cli 1.0.1
-# fetches through libgit2 with no credential callback, so anything that asks for
-# credentials fails with "remote authentication required but no callback set".
-# On Gitea, marking the repository public is not enough: a repository inside a
-# private organization is internal and still answers anonymous clones with 401.
+# fetches through libgit2 with no credential callback, so ssh:// cannot
+# authenticate at all and anything asking for credentials fails with "remote
+# authentication required but no callback set". On Gitea, marking the repository
+# public is not enough: a repository inside a private organization is internal
+# and answers an anonymous clone with 401, so the organization must be public.
 #
 # `strict_types` is deliberately absent. A camera publishes an image and nothing
 # else, and `dora validate --strict` warns about every *typed* input this node
@@ -19,7 +20,7 @@
 nodes:
   - id: camera
     git: https://gitea.liria.cl/liria/dora-webcam.git
-    tag: v0.1.0
+    tag: v0.1.1
     build: uv pip install .
     path: dora-webcam
     inputs: