docs: document limiting what the build can see

[dash14]

Summary

An allowlist decides which destinations a build can reach; it can't tell a legitimate use of an allowed one from an abusive one. A compromised dependency can read ~/.npmrc, take the npm token, and publish to registry.npmjs.org — which has to be allowlisted for npm ci to work at all. Nothing in the rule set stops that, and the docs didn't say what does.

Adds a Limiting What the Build Can See section to docs/security.md: don't put a token in the build unless the build needs it, and scope the ones it does need to the single RUN that needs them. README.md's Scope section gets the short version and links there.

Companion to buildcage/isolated-run#27, where the same problem is solved by splitting the step instead — this repo can't, since one builder serves the whole build and the allowlist doesn't vary per RUN.

Verifying the claim

The guidance depends on RUN --mount=type=secret still working through the remote driver, which wasn't covered. test/Dockerfile.transparent-restrict now asserts the secret is readable in the RUN that mounts it and absent from a later one, following the existing per-RUN exit 1 pattern rather than adding a matrix entry.

#26 [stage-0 21/23] RUN --mount=type=secret,id=testtoken ...
#26 0.042 ✓ secret readable in the RUN that mounts it
#27 [stage-0 22/23] RUN echo "=== [secret mount - later RUN] ===" ...
#27 0.050 ✓ secret absent from a RUN that does not mount it

The secret is passed for every matrix entry; an unmounted secret is never materialized, so the other three are unaffected.

Test plan

• make test_integration_buildkit_transparent_restrict passes, with both new steps confirmed in the build log
• vp check
• Relative links and anchors resolve