feat: lock down actions settings in apply-preferred-settings

[scode]

CI on these repos runs on paid, self-hosted-style runners. A public
repo accepts pull requests from any fork, and by default a fork PR's
workflow runs on the base repo's runners as soon as that account has
one merged PR — so anyone patient enough can run arbitrary code on
runners billed to me. Requiring approval for every external
contributor closes that; a read-only default token limits what an
approved run that turns out to be malicious can still do. Neither is
a hard ceiling (pull_request_target is never gated, and a workflow can
raise its own token permissions), which the docs now say plainly.

GitHub keeps two separate switches for this depending on visibility:
the approval policy exists only on public repos, and non-public repos
have their own fork-workflow controls instead. Rather than treating
the inapplicable one as drift, each repo gets whichever applies, and
for non-public repos the strictest option is taken: fork PR workflows
don't run at all.

Writes are now planned per endpoint from what actually drifted, so a
setting an organization has locked can't block the ones that matter.
The first_time_contributors variants are not accepted as
already-correct even though GitHub offers them — they are the very
defaults that let a once-merged account run workflows unattended.