content: draft: Clarify branch protection in source track (#1175)

Re: #1136

I'm trying to separate "branch protection" which is typically associated
with SCP features from the property we want for the branches intended
for consumption. I've also applied the SCS terminology we adopted in
another PR.

The framing of how this can be accomplished is still a bit TBD, if we
decide to adopt something like #1142 suggests, we could move the Git +
GitHub/GitLab piece out? That's also where we could discuss server side
pre-receive hooks etc.?

docs/spec/draft/source-requirements.md

@@ -155,8 +155,12 @@ This is a typical setup for teams who leverage code review tools.
 For all branches intended for consumption, whenever a branch is updated to point to a new revision, that revision MUST document how it related to the previous revision.
 Exceptions are allowed via the [safe expunging process](#safe-expunging-process).
 
-On VCS like git, the organization MUST enable branch protections that prohibit updating the branch to point to revisions that are not direct descendants of the current revision.
-At a minimum, this typically means preventing "force pushes" and "branch deletion."
+It MUST NOT be possible to rewrite the history of branches intended for
+consumption. In other words, when updating the branch to point to a new
+revision, that revision must be a direct descendant of the current revision. In
+an SCS that hosts a Git repository on systems like GitHub or GitLab, this can be
+accomplished by enabling branch protection rules that prevent force pushes and
+branch deletions.
 
 It MUST NOT be possible to delete the entire repository (including all branches) and replace it with different source.
 Exceptions are allowed via the [safe expunging process](#safe-expunging-process).