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.

README.md

@@ -85,12 +85,15 @@ 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.
 
+Verified end to end: dora clones dora-webcam at the pinned tag, builds both nodes, and
+runs them against a real camera to a clean exit.
+
 **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.
+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 a repository public is not sufficient — a repository inside a private
+organization is internal and answers an anonymous clone with `401`, so the organization
+has to be public too.
 
 ### Node manifest