fix(docs): Don't inherit @system notices from ancestry

[Josmithr]

It is valid for a non-@system API to extend a @system one. See here for more details on our tags, including @system. In fact, this is a common pattern - we introduce a base interface that some of our API members extend. We don't want customers to use that base interface directly, but it needs to exist for one reason or another. In this case, we don't want the implementations of that interface to inherit the @system notice.

AB#22762

[github-actions]

🔗 No broken links found! ✅

Your attention to detail is admirable.

linkcheck output

> fluid-framework-docs-site@0.0.0 ci:check-links /home/runner/work/FluidFramework/FluidFramework/docs
> start-server-and-test "npm run serve -- --no-open" 3000 check-links

1: starting server using command "npm run serve -- --no-open"
and when url "[ 'http://127.0.0.1:3000' ]" is responding with HTTP status code 200
running tests using command "npm run check-links"


> fluid-framework-docs-site@0.0.0 serve
> docusaurus serve --no-open

[SUCCESS] Serving "build" directory at: http://localhost:3000/

> fluid-framework-docs-site@0.0.0 check-links
> linkcheck http://localhost:3000 --skip-file skipped-urls.txt

Crawling...

Stats:
  170098 links
    1596 destination URLs
    1825 URLs ignored
       0 warnings
       0 errors

Copilot reviewed 1 out of 1 changed files in this pull request and generated no suggestions.

Comments skipped due to low confidence (1)

docs/infra/api-markdown-documenter/render-api-documentation.mjs:95

• The change from ancestryHasModifierTag to hasModifierTag may cause the function to miss @system tags inherited from parent items. Ensure this change aligns with the intended behavior of not inheriting @system notices from ancestry.

if (ApiItemUtilities.hasModifierTag(apiItem, "@system")) {

Tip: If you use Visual Studio Code, you can request a review from Copilot before you push from the "Source Control" tab. Learn more

[seanimam]

What do you think about using constants for these tag names?

[Josmithr]

Personally, I think the code reads more easily with them as inline literals, especially since they're each only used in one place AFAIK. I don't feel too strongly about this, but I think I will at least consider this beyond the scope of the PR.