Fixing heading level for accessibility

[protikbiswas100]

Description

Type of Change

Erase all that don't apply.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update
• Automation (AI changes or Github Actions to reduce effort of manual tasks)

Why

What is the motivation for this change? Add a few sentences describing the context and overall goals of the pull request's commits.

Resolves [Add Relevant Issue Here]

What

What changes were made to the codebase to solve the bug, add the functionality, etc. that you specified above.

Screenshots

Add any relevant screen captures here from before or after your changes.

Testing

If you added tests that prove your changes are effective or that your feature works, add a few sentences here detailing the added test scenarios.

Optional: Describe the tests that you ran locally to verify your changes.

Changelog

Should this change be included in the release notes: indicate yes or no

Add a brief summary of the change to use in the release notes for the next release.

Microsoft Reviewers: Open in CodeFlow

[sundaramramaswamy]

The PR description doesn't capture why you're making these changes. It seems your description is unedited and the template as-is. How is this useful to the PR?

Please drop template strings from PR description given for your guidance but not to pollute commit messages.

## Description

### Type of Change
_Erase all that don't apply._
- Bug fix (non-breaking change which fixes an issue)
- New feature (non-breaking change which adds functionality)
- Breaking change (fix or feature that would cause existing functionality to not work as expected)
- This change requires a documentation update
- Automation (AI changes or Github Actions to reduce effort of manual tasks)

### Why
What is the motivation for this change? Add a few sentences describing the context and overall goals of the pull request's commits.

Resolves [Add Relevant Issue Here]

### What
What changes were made to the codebase to solve the bug, add the functionality, etc. that you specified above.

## Screenshots
Add any relevant screen captures here from before or after your changes. 

## Testing
If you added tests that prove your changes are effective or that your feature works, add a few sentences here detailing the added test scenarios.

_Optional_: Describe the tests that you ran locally to verify your changes.

## Changelog
Should this change be included in the release notes: _indicate yes or no_

Add a brief summary of the change to use in the release notes for the next release.

 ###### Microsoft Reviewers: [Open in CodeFlow](https://microsoft.github.io/open-pr/?codeflow=https://github.com/microsoft/react-native-windows/pull/15191)

should be

## Description

Heading level of accessibility has problems

- Reason 1
- Reason 2
- ...

This commit fixes these issues: #issue1, ...

## Type of Change

- Bug fix

## Changelog
Should this change be included in the release notes: _indicate yes or no_

Add a brief summary of the change to use in the release notes for the next release.

Honestly, which one do you prefer reading if you were reviewing? Are you sure you're making it inviting/easy for a reviewer to give meaningful comments to improve this PR?

These template strings are just noise. Compare these messages with PRs from mature developers and notice the difference:

#14713 by Andrew
#15013 by Jon

[sundaramramaswamy]

PR title should be a short summary in imperative mood (Fix, not Fixing or Fixed).

A good commit message

• captures the why (context) not how / what (which git diff can always show)
• is succinct.

Please refer How to Write a Git Commit Message.