Add-ons: apply sentence-style capitalization to headings (#2185)

* Add-ons: apply sentence-style capitalization to headings

- to comply with MS Style Guide on [capitalization](https://learn.microsoft.com/en-us/style-guide/capitalization)

* Fix name

docs/add-ons/communication.md

@@ -1,5 +1,5 @@
 ---
-title: "Add-On Communication"
+title: "Add-on communication"
 ---
 
 There are different ways of communicating between add-ons inside Home Assistant.

docs/add-ons/configuration.md

@@ -1,5 +1,5 @@
 ---
-title: "Add-On Configuration"
+title: "Add-on configuration"
 ---
 
 Each add-on is stored in a folder. The file structure looks like this:
@@ -84,7 +84,7 @@ LABEL \
 
 It is possible to use your own base image with `build.yaml` or if you do not need support for automatic multi-arch building you can also use a simple docker `FROM`. You can also suffix the Dockerfile with the specific architecture to use a specific Dockerfile for a particular architecture, i.e. `Dockerfile.amd64`.
 
-### Build Args
+### Build args
 
 We support the following build arguments by default:
 

docs/add-ons/presentation.md

@@ -152,8 +152,7 @@ Ingress API gateway supports the following:
 - Streaming content
 - Websockets
 
-
-## Basic Ingress Example with Nginx
+## Basic ingress example with Nginx
 
 The following is a basic ingress implementation with an Nginx server. This contains an example`Dockerfile`, `config.yaml`, and `ingress.conf` configuration.
 

docs/add-ons/publishing.md

@@ -30,7 +30,7 @@ You can use `{arch}` inside the image name to support multiple architectures wit
 
 Home Assistant assumes that the default branch of your add-on repository matches the latest tag on the container registry. When you're building a new version, it's suggested that you use another branch, ie `build` or do it with a PR on GitHub. After you push the add-on to a container registry, you can merge this branch to master.
 
-## Custom Add-ons
+## Custom add-ons
 
 You need a Docker Hub account to make your own add-ons. You can build your container images with the Docker `build` command or use our [builder] to simplify the process. Pull our [Builder Docker engine][builder] and run one of the following commands.
 

docs/add-ons/security.md

@@ -4,11 +4,11 @@ title: "Add-on security"
 
 Home Assistant rates every add-on based on the wanted rights. An add-on with a rating of 6 is very secure. If an add-on has a rating of 1, you shouldn't run this add-on unless you are 100% sure that you can trust the source.
 
-## API Role
+## API role
 
 For access to the Supervisor API you need to define a role or run in default mode. This is only required for the Supervisor API and not the Home Assistant proxy. All of the roles already have access to the default API calls, and do not require any additional settings.
 
-### Available Roles
+### Available roles
 
 | Role | Description |
 |------|-------------|
@@ -36,7 +36,7 @@ As a developer, follow the following best practices to make your add-on secure:
 - If you need any API access, make sure that you do not grant permission that aren't needed
 - Sign the image with [Codenotary CAS](https://cas.codenotary.com/)
 
-## Use Home Assistant User backend
+## Use Home Assistant user backend
 
 Instead of allowing users to set new login credentials in plain text config, use the Home Assistant [Auth backend](/docs/api/supervisor/endpoints#auth). You can enable the access to the API with `auth_api: true`. Now you are able to send the login credentials to the auth backend and validate them in Home Assistant.
 

docs/api/native-app-integration/webview.md

@@ -1,5 +1,5 @@
 ---
-title: "Authenticated Webview"
+title: "Authenticated WebView"
 ---
 
 Your application already asked the user to authenticate. This means that your app should not ask the user to authenticate again when they open the Home Assistant UI.