docs(contributing): drop --branch next/major from clone snippet; clarify PR target (#3198)

* docs(contributing): drop --branch next/major from clone snippet; clarify PR target

The recommended clone command pinned `--branch next/major`, which left
contributors landing on a long-lived feature branch instead of `master`
(the actual default branch and PR target). I tripped on this myself
and opened #3196 against `next/major` before noticing every other open
PR targets `master`.

Drop the `--branch next/major` flag so a fresh clone lands on the
default, and add a short note explaining that `master` is the PR
target while `next/major` is reserved for the next major release.

* docs(contributing): expand branch policy per @dr-bonez

Adopt the maintainer-authored explanation of the branch-targeting
policy verbatim: master tracks the current release (and during a
beta.X pre-release, PRs for new features and bugfixes land there),
with next/{patch,minor,major} holding work waiting for the
corresponding future release.

---------

Co-authored-by: Helix <helix-nine@start9.com>

Author: helix-nine

CONTRIBUTING.md

@@ -39,10 +39,12 @@ nvm alias default 24 # this prevents your machine from reverting back to another
 ### Cloning the Repository
 
 ```sh
-git clone --recursive https://github.com/Start9Labs/start-os.git --branch next/major
+git clone --recursive https://github.com/Start9Labs/start-os.git
 cd start-os
 ```
 
+StartOS has 4 major branches for integration. `master` is for the current release. If the current latest release is a pre-release (i.e. "beta.X"), PRs for new features and bugfixes should go here. Otherwise we have `next/` branches depending on which release of StartOS the changes should be included in; `next/patch` for the next patch release, `next/minor` for the next minor release, and `next/major` for the next major release. If you are unsure which branch to target, ask a maintainer.
+
 ### Development Mode
 
 For faster iteration during development: