docs: remove unused rootDir from parse JSDoc

[MOHITKOURAV01]

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• Prefix your PR title with feat:, fix:, chore:, or docs:.
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.
• If this PR changes code within packages/svelte/src, add a changeset (npx changeset).

Tests and linting

• Run the tests with pnpm test and lint the project with pnpm lint

---

Description

This PR fixes a documentation inconsistency in the parse function located in packages/svelte/src/compiler/index.js.

Problems Solved:

The parse function's JSDoc included a rootDir parameter, but this option was neither destructured nor used in the actual implementation. This could lead to confusion for developers expecting the rootDir option to have an effect.

Changes:

• Removed rootDir from the JSDoc @param definition for the parse function.
• Maintained the existing filename documentation which is marked for removal in Svelte 6.0.
• Added a changeset (patch) for the svelte package.

Verification:

• Verified consistency between JSDoc and function signature.
• Ran pnpm build to ensure the package compiles correctly.
• Ran pnpm lint and pnpm check to confirm that all quality checks and type validations pass.

[changeset-bot]

🦋 Changeset detected

Latest commit: 0dbfa68

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
svelte	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[dummdidumm]

We can't just remove it because it's public API but it does beg the question why this was ever added.

[MOHITKOURAV01]

@dummdidumm Since its public API, we can’t remove it without a deprecation cycle. It was likely added for context or anticipated use that never materialized, and at this point its just unused surface area. Deprecating it now and removing it in a major version seems like the right balance between API stability and cleanup.

[Rich-Harris]

if anyone is able to figure out a sensible way to mark options as deprecated in JSDoc then have at it; will close this PR in the meantime