feat: add fenced-code-meta rule

[TKDev7]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request?

This pull request introduces a new rule, fenced-code-meta, that enforces a consistent policy for metadata in fenced code block info strings. It allows teams to require metadata when a language is specified or to disallow metadata entirely.

What changes did you make? (Give an overview)

• Added a rule that validates the presence or absence of metadata based on the configured mode
• Added documentation
• Added tests

Related Issues

Fixes #477

Is there anything you'd like reviewers to focus on?

[Copilot]

Pull Request Overview

This pull request introduces a new ESLint rule fenced-code-meta that enforces consistent policies for metadata in fenced code block info strings. The rule can either require metadata when a language is specified ("always" mode) or disallow metadata entirely ("never" mode).

• Added a new rule that validates the presence or absence of metadata in fenced code blocks
• Comprehensive test coverage for both backtick and tilde fenced code blocks with various configurations
• Complete documentation with examples and usage guidelines

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
src/rules/fenced-code-meta.js	Implements the core rule logic for validating fenced code block metadata
tests/rules/fenced-code-meta.test.js	Comprehensive test suite covering valid and invalid cases for both rule modes
docs/rules/fenced-code-meta.md	User documentation with examples and configuration options
README.md	Updates rule table and formatting improvements for ESLint disable comments

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[nzakas]

Thanks for working on this. Overall it looks good. I think the Copilot comments bring up good points, so please take a look at those. Also, double-check the CI errors.

[nzakas]

LGTM. Would like another review before merging.

[lumirlumir]

If we don't use dedent, the rendered output will include the indentation.

Since more than four spaces of indentation is recognized as code block syntax, we won't get the exact result we expect.

This applies to all multiline test cases, except those with specific intent.

[lumirlumir]

Suggested change

	- "always" (default): Require metadata when a language is specified.
	- "never": Disallow metadata in the info string.
	- `"always"` (default): Require metadata when a language is specified.
	- `"never"`: Disallow metadata in the info string.

Since these are code-related options, I think adding backticks would make sense.

[lumirlumir]

Suggested change

	~~~js title="example.js"
	console.log("Hello, world!");
	~~~
	```
	Examples of **correct** code when configured as `"fenced-code-meta": ["error", "never"]`:
	```markdown
	<!-- eslint markdown/fenced-code-meta: ["error", "never"] -->
	~~~js
	console.log("Hello, world!");
	~~~
	```js title="example.js"
	console.log("Hello, world!");
	```
	````
	Examples of **correct** code when configured as `"fenced-code-meta": ["error", "never"]`:
	````markdown
	<!-- eslint markdown/fenced-code-meta: ["error", "never"] -->
	```js
	console.log("Hello, world!");
	```

I think a consistent approach to the examples would make the different behaviors of the options clearer.

[lumirlumir]

Could we also add tests to make sure it works correctly with indented code blocks?

[snitin315]

Suggested change

	Fenced code blocks can include an info string after the opening fence. The first word typically specifies the language (e.g., `js`). Many tools also support additional metadata after the language (separated by whitespace), such as titles or line highlighting parameters. This rule enforces a consistent policy for including such metadata.
	Fenced code blocks can include an information string after the opening fence. The first word typically specifies the language (e.g., `js`). Many tools also support additional metadata after the language (separated by whitespace), such as titles or line highlighting parameters. This rule enforces a consistent policy for including such metadata.

[snitin315]

I suggest we define a schema option for more flexibility, like { required: "always" | "never" } or { required: boolean }. This approach would make it easier to extend the options in the future without introducing breaking changes. I’d like to hear the team’s thoughts on this.