feat: Set up markdownlint GitHub Action for automated linting (Closes #14)

[EmersonFras]

Summary

Establishes automated markdown linting using GitHub Actions. As noted in the issue, this ensures consistent formatting across the repository without requiring manual nitpicks during code review.

Changes Implemented

• Added .github/workflows/lint.yaml: A workflow that runs markdownlint-cli2 on pull requests.
• Updated CONTRIBUTING.md: Documentation for the new linting automation.

Testing

To verify the automation, I pushed a commit containing intentional formatting errors (cda3921).

1. Verification of Failure
The workflow correctly detected the changes and failed the build as expected:

2. Error Reporting
The logs accurately highlighted the specific rule violations (e.g., indentation, invalid headers) within the test file:

---

Closes #14

[egrace479]

This is great--really appreciate the demo commit screenshots!

Could we have the workflow set up with the -f flag to fix the smaller issues that were highlighted? We would want people to be able to see issues that shouldn't/couldn't be auto-fixed (ex: [here](link-to-something) should be fixed by user to have more descriptive text in place of "here").

[EmersonFras]

This is great--really appreciate the demo commit screenshots!

Could we have the workflow set up with the -f flag to fix the smaller issues that were highlighted? We would want people to be able to see issues that shouldn't/couldn't be auto-fixed (ex: [here](link-to-something) should be fixed by user to have more descriptive text in place of "here").

@egrace479, I've set up the fix logic and tested it. It successfully identifies errors, fixes them, and pushes a commit back to the branch.

However, there is what I think is a GitHub Actions limitation, that when the default GITHUB_TOKEN pushes the auto-fix commit, GitHub prevents it from triggering a new CI workflow run (to prevent infinite loops).

This creates an issue where someone pushes an MD file with errors. The bot fixes the files and pushes a new commit. The latest commit (the bot's) has no CI run associated with it. If there were unfixable errors remaining (like duplicate headers), the user wouldn't see a "Red X" on the PR. They would have to know to click into the previous commit's logs to see what is wrong.

Now there might be a way to make this work using a PAT with repo permissions and adding it as a Secret (BOT_TOKEN). Then updating the workflow to use that token. I think this would allow the bot's commit to trigger a new run and report status correctly but not sure if that's the route we want to take for this.

Alternatively, we remove the auto-fix/push logic. Users will have to fix formatting manually, but they will get immediate, reliable Red/Green feedback on every push.

Let me know what you think of these options, along with if you have any other solutions in mind or see any other reason causing this.

[egrace479]

This is great--really appreciate the demo commit screenshots!
Could we have the workflow set up with the -f flag to fix the smaller issues that were highlighted? We would want people to be able to see issues that shouldn't/couldn't be auto-fixed (ex: [here](link-to-something) should be fixed by user to have more descriptive text in place of "here").

@egrace479, I've set up the fix logic and tested it. It successfully identifies errors, fixes them, and pushes a commit back to the branch.

However, there is what I think is a GitHub Actions limitation, ...
Let me know what you think of these options, along with if you have any other solutions in mind or see any other reason causing this.

@EmersonFras, thanks for the detailed explanation with proposed solutions. We should just remove the auto-fix to make it more robust. We can add a brief explanation in CONTRIBUTING.md to check the details from the action when the workflow fails.

[egrace479]

A couple notes and a question.

[egrace479]

LGTM!