refactor(docs): Document and enforce header casing conventions

docs/docs/features/backlight.mdx

@@ -34,7 +34,7 @@ There are various Kconfig options used to configure the backlight feature. These
 | `CONFIG_ZMK_BACKLIGHT_AUTO_OFF_IDLE` | Turn off backlight when keyboard goes into idle state | n       |
 | `CONFIG_ZMK_BACKLIGHT_AUTO_OFF_USB`  | Turn off backlight when USB is disconnected           | n       |
 
-## Adding Backlight to a board or a shield
+## Adding Backlight to a Board or a Shield
 
 <Tabs
 defaultValue="shieldpin"
@@ -208,7 +208,7 @@ Finally you need to add backlight to the `chosen` element of the root devicetree
 </TabItem>
 </Tabs>
 
-### Multiple backlight LEDs
+### Multiple Backlight LEDs
 
 It is possible to control multiple backlight LEDs at the same time. This is useful if, for example, you have a Caps Lock LED connected to a different pin and you want it to be part of the backlight.
 

docs/docs/features/beta-testing.mdx

@@ -28,7 +28,7 @@ branch and create the pull request.
 
 ![Repository URL](../assets/features/beta-testing/repo-branch.png)
 
-## Testing features
+## Testing Features
 
 Testing features will require you to modify the `west.yml` file. You will need to add a new remote for the pull request you
 would like to test, and change the selected remote and revision (or branch) for the `zmk` project.

docs/docs/features/combos.md

@@ -38,7 +38,7 @@ Key positions are numbered like the keys in your keymap, starting at 0. So, if t
 
 :::
 
-### Advanced usage
+### Advanced Usage
 
 - Partially overlapping combos like `0 1` and `0 2` are supported.
 - Fully overlapping combos like `0 1` and `0 1 2` are supported.

docs/docs/features/debouncing.md

@@ -40,7 +40,7 @@ CONFIG_ZMK_KSCAN_DEBOUNCE_PRESS_MS=3
 CONFIG_ZMK_KSCAN_DEBOUNCE_RELEASE_MS=3
 ```
 
-### Per-driver Options
+### Per-Driver Options
 
 You can add these Devicetree properties to a kscan node to control debouncing for
 that instance of the driver. Values must be `<= 16383`.

docs/docs/features/keymaps.mdx

@@ -96,7 +96,7 @@ The first defines the nodes for all the available behaviors in ZMK, which will b
 
 The second include brings in the defines for all the keycodes (e.g. `A`, `N1`, `C_PLAY`) and the modifiers (e.g. `LSHIFT`) used for various behavior bindings.
 
-### Root devicetree Node
+### Root Devicetree Node
 
 All the remaining keymap nodes will be nested inside of the root devicetree node, like so:
 

docs/docs/features/soft-off.md

@@ -101,7 +101,7 @@ To use the [soft off behavior](../behaviors/soft-off.md) outside of a keymap, ad
 
 The kscan sideband behavior driver will be used to trigger the [soft off behavior](../behaviors/soft-off.md) "out of band" from the normal keymap processing. To do so, it will decorate/wrap an underlying kscan driver. What kscan driver will vary for simple direct pin vs. matrix-integrated hardware combo.
 
-#### Simple Direct Pin
+#### Simple direct pin
 
 With a simple direct pin setup, the The [direct kscan](../config/kscan.md) driver can be used with a GPIO key, to make a small "side matrix":
 
@@ -148,7 +148,7 @@ Here are the properties for the node:
 - The `compatible` property for the node must be `zmk,soft-off-wakeup-sources`.
 - The `wakeup-sources` property is a [phandle array](../config/index.md#devicetree-property-types) pointing to all the devices that should be enabled during the shutdown process to be sure they can later wake the keyboard.
 
-#### Matrix-Integrated Hardware Combo
+#### Matrix-integrated hardware combo
 
 For this case, you will supplement the existing kscan matrix, by adding the additional pin as another entry in
 the `row-gpios`/`col-gpios` for whichever pins are used to read the matrix state. For example, for an existing matrix like:

docs/docs/features/underglow.md

@@ -39,7 +39,7 @@ use Kconfig.
 
 If your board or shield does not have RGB underglow configured, refer to [Adding RGB Underglow to a Board](#adding-rgb-underglow-to-a-board).
 
-### Modifying the number of LEDs
+### Modifying the Number of LEDs
 
 A common issue when enabling underglow is that some of the installed LEDs do not illuminate. This can happen when a board's default underglow configuration accounts only for either the downward facing LEDs or the upward facing LEDs under each key. On a split keyboard, a good sign that this may be the problem is that the unilluminated LEDs on each half are symmetrical.
 
@@ -64,7 +64,7 @@ If you have a shield with RGB underglow, you must add a `boards/` directory with
 Inside the `boards/` folder, you define a `<board>.overlay` for each different board.
 For example, the Kyria shield has a `boards/nice_nano.overlay` file that defines the RGB underglow for the `nice_nano` board specifically.
 
-### nRF52-based boards
+### nRF52-Based Boards
 
 With nRF52 boards, you can just use `&spi3` and define the pins you want to use.
 
@@ -128,7 +128,7 @@ If your board/shield uses LEDs that require the data sent in a different order,
 
 :::
 
-### Other boards
+### Other Boards
 
 For other boards, you must select an SPI definition that has the `MOSI` pin as your data pin going to your LED strip.