fix(linter): Fix config option docs for react/jsx-boolean-value rule.

[connorshea]

Implement a proper tuple config so the resulting docs actually match the implemented rule. Also enforce the config options' validity by using TupleRuleConfig.

Also improve the documentation to make it easier to understand what the rule and config options actually do.

Part of #16023.

Generated docs:

### Examples

Examples of **incorrect** code for this rule with default `"never"` mode:

```jsx
const Hello = <Hello personal={true} />;
```

Examples of **correct** code for this rule with default `"never"` mode:

```jsx
const Hello = <Hello personal />;

const Foo = <Foo isSomething={false} />;
```

Examples of **incorrect** code for this rule with `"always"` mode:

```jsx
const Hello = <Hello personal />;
```

Examples of **correct** code for this rule with `"always"` mode:

```jsx
const Hello = <Hello personal={true} />;
```

## Configuration

### The 1st option

type: `"always" | "never"`

#### `"always"`

All boolean attributes must have explicit values.

#### `"never"`

All boolean attributes must omit values that are set to `true`.

### The 2nd option

This option is an object with the following properties:

#### always

type: `string[]`

default: `[]`

List of attribute names that should always have explicit boolean values.
Only necessary when main mode is `"never"`.

#### assumeUndefinedIsFalse

type: `boolean`

default: `false`

If `true`, treats `prop={false}` as equivalent to the prop being `undefined`.
When combined with `"never"` mode, this will enforce that the attribute is omitted entirely.

```jsx
// With "assumeUndefinedIsFalse": true
<App foo={false} />; // Incorrect
<App />; // Correct
```

This option does nothing in `"always"` mode.

#### never

type: `string[]`

default: `[]`

List of attribute names that should never have explicit boolean values.
Only necessary when main mode is `"always"`.

AI Disclosure: Built with help from Claude Code + Opus 4.5, docs updates written manually by me.

My only real concern with this change is that the pre-calculation of "exceptions" no longer happens as part of the config parsing, and instead happens during the rule's code checks. This is going to be slower, but I'm not sure how much slower.

[Copilot]

Pull request overview

This PR refactors the react/jsx-boolean-value linter rule to use the TupleRuleConfig pattern for proper tuple-based configuration, enabling accurate documentation generation for rules that accept tuple options.

Changes:

• Refactored config parsing from manual JSON parsing to using TupleRuleConfig for automatic deserialization and validation
• Replaced single exceptions field with separate always and never fields in JsxBooleanValueOptions for better clarity
• Enhanced documentation with improved examples showing both "always" and "never" modes, and added detailed inline comments for config options

---

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

[codspeed-hq]

Merging this PR will not alter performance

✅ 46 untouched benchmarks
⏩ 3 skipped benchmarks¹

---

_{Comparing update-jsx-bool-value-rule (fbb9561) with main (41f92d1)}

Footnotes

1. 3 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[camc314]

Merge activity

• Feb 1, 10:17 PM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Feb 1, 10:17 PM UTC: camc314 added this pull request to the Graphite merge queue.
• Feb 1, 10:35 PM UTC: Merged by the Graphite merge queue.