Use Wayback Machine snapshot for WAC 1.1 link

Use https://web.archive.org/web/20260425225256/... as a permanent
reference for the WAC 1.1 ED while https://solidproject.org/TR/2026/
wac-20260420 is being created in #784. Once that snapshot PR is
merged, this link should be swapped to the immutable TR URL.

Author: jeswr

solid26.html

@@ -384,7 +384,7 @@ <h3>Solid Protocol</h3>
                       <p>
                         The Solid Protocol requires Servers to conform to Web Access Control (<a href="#web-access-control">WAC</a>), Access Control Policy (<a href="#access-control-policy">ACP</a>), or both, and requires Clients to conform to both. In practice, Clients typically conform to one. A Client that conforms to only one and needs to read or write access-control rules will not interoperate with a Server that implements only the language the Client does not support; Clients that do not interact with access-control rules are unaffected. Implementers choosing between the two should consider the requirements satisfied by each.
                       </p>
-                      <p>WAC is the simpler and extensible access-control language, covering the cases used by most current Solid applications. Its policies are RDF with monotonic semantics &mdash; adding or removing triples preserves the truth of existing grants. Optional <code>acl:origin</code> matching is not intended as client identification [<cite><a class="bibref" href="#ref-wac">WAC</a></cite> § <a href="https://solidproject.org/TR/2024/wac-20240512#security-privacy-review">Security and Privacy Review</a>]. WAC 1.0 (pinned here) does not express deny rules, application-aware matching beyond Origin, or conditional grants. Application-aware matching and conditional grants land as <code>acl:condition</code> in <a href="https://solid.github.io/web-access-control-spec/">WAC 1.1 ED</a>, with no implementations known at the time of publication.</p>
+                      <p>WAC is the simpler and extensible access-control language, covering the cases used by most current Solid applications. Its policies are RDF with monotonic semantics &mdash; adding or removing triples preserves the truth of existing grants. Optional <code>acl:origin</code> matching is not intended as client identification [<cite><a class="bibref" href="#ref-wac">WAC</a></cite> § <a href="https://solidproject.org/TR/2024/wac-20240512#security-privacy-review">Security and Privacy Review</a>]. WAC 1.0 (pinned here) does not express deny rules, application-aware matching beyond Origin, or conditional grants. Application-aware matching and conditional grants land as <code>acl:condition</code> in <a href="https://web.archive.org/web/20260425225256/https://solid.github.io/web-access-control-spec/">WAC 1.1 ED</a>, with no implementations known at the time of publication.</p>
                       <p>ACP is the more expressive alternative, suited to requirements that go beyond what WAC can directly express. Policies can carry allow and deny rules in the same document with non-monotonic semantics, so a deny rule can override a prior allow. Subjects can additionally be identified by the <em>application</em> making the request via the <code>acp:client</code> matcher, and rules composed via <code>acp:allOf</code>, <code>acp:anyOf</code>, and <code>acp:noneOf</code>, supporting context-aware policies.</p>
                       <div class="note" id="note-survey">
                         <h4><span>Note</span></h4>