feat(nns): apply 8 Year Gang 10% bonus to voting power calculation

[jasonz-dfinity]

Why

Neurons that had the maximum dissolve delay (8 years) before Mission 70 reduced it to 2 years
should receive a grandfathered 10% voting power bonus. The bonus base (eight_year_gang_bonus_base_e8s)
was already tagged on qualifying neurons (#9593) and exposed in neuron info (#9687), but was not yet
wired into the actual voting power calculation.

What

• Add eight_year_gang_bonus() helper in voting_power.rs that returns 10% of the bonus base
• Include the bonus in potential_and_deciding_voting_power: effective stake becomes
  stake + eight_year_gang_bonus(bonus_base) before dissolve delay and age multipliers are applied
• Cap the bonus base to stake_e8s to prevent rejection fees from inflating the bonus
• Add a test verifying the cap behavior

Testing

• Unit test for the capping behavior added in types/tests.rs
• All existing governance tests pass (12 bazel test targets)

[Copilot]

Pull request overview

Wires the previously-tagged eight_year_gang_bonus_base_e8s into the NNS neuron voting power computation by adding a 10% “8-year gang” bonus (capped to current stake) to the effective stake before dissolve-delay and age multipliers are applied.

Changes:

• Add eight_year_gang_bonus() helper to compute 10% of the bonus base.
• Update potential_and_deciding_voting_power to include the bonus and cap the bonus base to stake_e8s.
• Add a unit test verifying the bonus base cap behavior when stake is reduced by fees.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
rs/nns/governance/src/neuron/voting_power.rs	Adds helper to compute the 8-year gang bonus amount.
rs/nns/governance/src/neuron/types.rs	Applies capped 8-year gang bonus into potential/deciding voting power calculation.
rs/nns/governance/src/neuron/types/tests.rs	Adds unit test to ensure bonus base is capped to current stake.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

This pull request changes code owned by the Governance team. Therefore, make sure that
you have considered the following (for Governance-owned code):

1. Update unreleased_changelog.md (if there are behavior changes, even if they are
   non-breaking).

2. Are there BREAKING changes?

3. Is a data migration needed?

4. Security review?

How to Satisfy This Automatic Review

1. Go to the bottom of the pull request page.

2. Look for where it says this bot is requesting changes.

3. Click the three dots to the right.

4. Select "Dismiss review".

5. In the text entry box, respond to each of the numbered items in the previous
   section, declare one of the following:

• Done.

• $REASON_WHY_NO_NEED. E.g. for unreleased_changelog.md, "No
  canister behavior changes.", or for item 2, "Existing APIs
  behave as before.".

Brief Guide to "Externally Visible" Changes

"Externally visible behavior change" is very often due to some NEW canister API.

Changes to EXISTING APIs are more likely to be "breaking".

If these changes are breaking, make sure that clients know how to migrate, how to
maintain their continuity of operations.

If your changes are behind a feature flag, then, do NOT add entrie(s) to
unreleased_changelog.md in this PR! But rather, add entrie(s) later, in the PR
that enables these changes in production.

Reference(s)

For a more comprehensive checklist, see here.

GOVERNANCE_CHECKLIST_REMINDER_DEDUP

N/A behind feature flag