[PATCH] doc: document two-pass promisor remote fetch order

[Edson <edsonwasswa54@gmail.com>]

The "Using many promisor remotes" section in the partial-clone design
documentation describes how promisor remotes are configured and the order
in which they are tried. However, it does not mention that servers can
advertise promisor remotes via the protocol v2 "promisor-remote"
capability, and that such server-accepted remotes are tried before other
configured promisor remotes.

The implementation uses a two-pass approach: first try accepted remotes
(those advertised by the server and accepted by the client), then try
all configured promisor remotes. Document this behavior to make the
technical design notes complete.

This patch also clarifies the security model for server-advertised promisor
remotes. Advertising a remote does not, by itself, make the client accept
or trust it. By default, clients reject all server-advertised promisor
remotes (the promisor.acceptFromServer default is "none"). A client only
accepts an advertised remote when the user explicitly configures an
acceptance policy via promisor.acceptFromServer or promisor.acceptFromServerUrl.
This prevents servers from arbitrarily directing clients to fetch from
untrusted repositories, addressing the concern that a server might inject
a brand-new, untrusted promisor remote configuration.

Reference the gitprotocol-v2 documentation for protocol details rather
than duplicating the information.

Signed-off-by: Edson <edsonwasswa54@gmail.com>
---
 Documentation/technical/partial-clone.adoc | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/technical/partial-clone.adoc b/Documentation/technical/partial-clone.adoc
index a1104930fb..f80346729b 100644
--- a/Documentation/technical/partial-clone.adoc
+++ b/Documentation/technical/partial-clone.adoc
@@ -199,6 +199,10 @@ until all the objects have been fetched.
 When a server advertises promisor remotes via the protocol v2
 "promisor-remote" capability and the client accepts them (see
 linkgit:gitprotocol-v2[5]), those accepted remotes are tried first.
+Note that clients only accept server-advertised promisor remotes when
+explicitly configured to do so via the `promisor.acceptFromServer` or
+`promisor.acceptFromServerUrl` options (see linkgit:git-config[1]),
+which prevents arbitrary injection of untrusted remotes by servers.
 After trying the accepted remotes, Git then tries the other configured
 promisor remotes as described below.
 
-- 
2.46.0.windows.1