Define settings-driven default release bumps #225

Context and request

Define a configurable automatic release bump in the existing MSXOrg/docs#196 guidance. The user chose DefaultBump to replace a patch-specific AutoPatching switch: documented defaults make automation usable, supported caller settings change that default, and an explicit owned bump label overrides the effective setting.

Acceptance criteria

• The guidance explains the effective documented default, supported patch/minor/major choices, caller overrides, and explicit-label precedence consistently.
• A valid effective default supplies a release level without requiring a bump label on every PR; invalid settings and conflicting owned signals fail explicitly.
• Canonical mode and stop labels are release:prerelease and release:skip; dependency metadata and bare labels do not select a release level.
• Release, PR-format, continuous-delivery, and applicable framework references agree without silently reverting the reconciled mainline consumer-evidence contract.
• Existing documentation validation and the complete review loop pass, and the existing PR conflicts are resolved without discarding other work.

Technical decisions

Use existing PR #196, preserving its distinct settings proposal and coordinating overlapping changes with #209/#208 under one owner. Reuse the shared smart-defaults/local-overrides principle and retain public setting precedence in the release capability. Date-based versioning remains an idea, not a supported value or implementation requirement. This Task changes canonical guidance, not producer code, labels, rulesets, or publication state. CI enforcement is tracked separately by #166 through the native dependency.

Implementation plan

• Inspect the complete current candidate/main differences and identify all default-policy and label references before editing.
• Establish checks for default/override/prerelease/skip/error cases in the guidance.
• Align the canonical settings and dependent references with those cases while preserving separately scoped PR intent.
• Reconcile conflicts and execute existing documentation checks and the complete Copilot review loop.
• Record settings decisions and acceptance evidence in PR Release guidance uses keyed release types #196 and link this Task with a closing reference.

Release settings filename revision

The user-directed filename is .github/release.settings.yml; only the filename changes. Preserve the settings/default/override contract and all unrelated interfaces. Landed #209/main aa9b5cecc69f4cbe6aa04a5dd70ff9cdadeeac3d supplies the complete PR-record, release-range-first, and no-template-file contracts during the authorized consistency reconciliation. The canonical filename follow-up has a separate owner; no unmerged delivery is copied here.

• Locate all owned filename references and establish regression failures before editing.
• Update the owned release/default guidance and directly relevant tests.
• Reconcile landed main while preserving the DefaultBump/keyed-route scope and verify exact shared-page composition with the canonical filename owner.
• Run documentation validation and current-head review, then push the scoped revision.

Existing human/source/lineage/prerequisite holds remain; automatic merging is not authorized.

Merge-readiness revision

The user asked to fix the remaining readiness issues after the latest main reconciliation. Remove the added documentation-string-only suite to follow the landed functional-testing policy; preserve all functional tests, linters, link validation, builds, and required checks. Refresh the actual current PR record and run a new review on that source. This does not authorize merging, auto-merge, self-approval, or a ruleset bypass.

• Verify the current head, actual base, scoped test-policy conflict, and stale evidence.
• Remove the prose-only suite, run the remaining functional suites, and push the focused commit.
• Refresh the PR description around the actual current diff and validation identities.
• Clarify inherited stable-route duplicate validation and candidate prerelease publication from the concrete review findings.
• Make the existing fixed-key and inherited-assignment validation guarantees explicit in the normative spec.
• Complete current-head CI and automated review, inspect the full result, and record the disposition.

Independent last-push approval and existing human/source/lineage holds are not waived.