Fix documentation on rollout specification for autoPromotionEnabled b…

[sncariad]

…eing true

As the autoPromotionEnabled is by default true when not specified the example in docs is misleading

Checklist:

• Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this is a chore.
• The title of the PR is (a) conventional with a list of types and scopes found here, (b) states what changed, and (c) suffixes the related issues number. E.g. "fix(controller): Updates such and such. Fixes #1234".
• I've signed my commits with DCO
• My builds are green. Try syncing with master if they are not.
• I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
• I have run all tests locally (including the flaky ones) and they pass on my workstation
• I have used LLM/AI/Agent tools for this PR but I am responsible for all code of this PR
• I understand what the code does and WHY/HOW it works in several scenarios
• I know if my code is just adding new functionality or changing old functionality for existing users
• My organization is added to USERS.md.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Published E2E Test Results

  4 files    4 suites   4h 2m 21s ⏱️
120 tests 104 ✅  7 💤  9 ❌
502 runs  455 ✅ 28 💤 19 ❌

For more details on these failures, see this check.

Results for commit 2db7c67.

[github-actions]

Published Unit Test Results

2 469 tests   2 469 ✅  3m 21s ⏱️
  129 suites      0 💤
    1 files        0 ❌

Results for commit 2db7c67.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.00%. Comparing base (2ccdae8) to head (2db7c67).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4718      +/-   ##
==========================================
- Coverage   85.03%   85.00%   -0.04%     
==========================================
  Files         164      164              
  Lines       18989    18989              
==========================================
- Hits        16148    16142       -6     
- Misses       1993     1996       +3     
- Partials      848      851       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[kostis-codefresh]

Actually it is the other way around. In most cases in the spec file the default is mentioned in the comments, and the example value shows how you OVERRIDE something.

Some quick examples:

• minPodsPerReplicaSet default is 1, but the spec shows how to override to 2
• scaleDownDelayRevisionLimit default is nil, but the spec shows how to override to 2

So in the case of autoPromotionEnabled, the comment says default is true and the example value shows how to override with false.

It is true that there are some cases that don't follow this pattern (quick example would be progressDeadlineSeconds). But just changing autoPromotionEnabled on its own doesn't really clear up anything and it will be confusing to the next reader.

I believe a better PR would be to fix the remaining values in the spec to be uniform with everything else (i.e. mention default in comment and show example of override).