Adjust documentation website to import C++ sdk documentation

[bcastets-robotiq]

• Render C++ sdk doxygen API documentation
• Render C++ readme and attached md documentation files
• Provide instructions about how to document C++ repository and import it to the documentation website

[ebarnett3]

Scope: main...feature/cpp-api-docs.
Verified locally: npm ci, npm run generate, npx docusaurus build and
npm test all run; the build passes and the working tree stays clean
afterwards. Findings 1, 2 and 3 were confirmed against the generated
output rather than read off the diff.

Rendered check (2026-09-11/12): the site was regenerated on this branch
with SKIP_SUBMODULE_RESET=1 and external/2f85_cpp checked out at the
grippers documentation-update branch (859a2a4), then browsed under
http://localhost:3000/docs/drivers/2F%20hande/SDK/C++/. Findings 1-4
reproduce on the rendered pages; findings 9 and 10 come from that pass.
docusaurus build at ca3a554 still passes with the one broken-anchor
warning from finding 4.

Findings 1-11 are inline. 12. Noted during the rendered pass — fine to fix in later work (info)

None of these needs to land in this PR; they are recorded here so they are
not lost.

• Homepage cards are not links. src/components/HomepageFeatures/index.js
  renders Sense / Grip / Integrate as <div> + <img> with no <Link>,
  same as on main and on the live site; this PR only swaps the ROS2 logo
  path. Wrapping styles.featureCard in <Link to=…> is a separate change.
• //! leaks into the Core API diagram. API/groups/core-api shows the
  block diagram with a //! prefix on every line and the following \note
  rendered as raw text. The markers are already in Doxygen's XML
  (group__core__api.xml:17-36, inside <verbatim>), so this is a
  grippers-side issue: groups.dox uses \verbatim inside a //! comment,
  and Doxygen keeps the comment markers there where \code stripped them.
  That change was made at my request during the grippers #26 review, so the
  fix belongs there: \code{.unparsed} or a /*! … */ block for that
  section.
• Dev workflow. Running npm run generate or docusaurus build while
  npm start is up rewrites .docusaurus/ under the dev server and leaves
  the open tab requesting chunks that no longer exist (ChunkLoadError,
  "Unexpected token '<'"); npm run clear and a restart recover. Worth one
  sentence in docs/contribute/index.mdx next to the preview instructions.

[mbegin-robotiq]

Test coverage

Leaving the review findings aside, I want to flag the pattern behind them rather than just the individual bugs.

This PR adds ~1,800 lines, of which scripts/sync-external-docs.js is now 1,281 lines and 40+ top-level functions. Most of those are pure string-in/string-out transforms: stripDeadDoxygenLinks, mergeMemberIndexTables, moveDetailedDescriptionToTop, splitTopLevelParams, splitMemberSignatures, doxygenSidebarOutputPath. The file exports nothing, so none of them is reachable from a test.

What we have today is npm test → scripts/check-build.js: 5 pages exist, the intro page has a <table> with a badge. That is a genuinely good smoke test and the comment at the top is right that onBrokenLinks: 'throw' carries most of the weight. But it runs after a full Doxygen + Docusaurus build and asserts almost nothing about the ~18 generated API pages this PR introduces.

The result is visible in this review. Of the findings raised across both passes, 11 are one-assertion unit tests — I wrote and ran each of them against ca3a554 and every one fails; they're posted inline on the relevant threads. None needed a build, a submodule, or Doxygen; the slowest took milliseconds. The remaining ones split into content assertions on the generated tree (Members index ordering, pages whose <title> is their slug, duplicated sidebar labels) and environment gaps.

Three concrete asks:

1. Make the transforms testable. Add module.exports = { ... } at the bottom of sync-external-docs.js behind a require.main === module guard, and a "test:unit": "node --test" script. Node 20 has the runner built in — no new dependency. The 11 tests above are then the starting suite.

2. Assert on the generated tree, not just that it exists. Extend check-build.js, or add a second check that runs after npm run generate: no page <title> equal to its own slug, ## Members appearing before the first detail section on class pages, no sidebar label appearing twice under one parent. Each of those corresponds to a defect found by hand-browsing localhost in this cycle.

3. Cover the degraded paths in CI. CI is one job: Ubuntu, all submodules present, doxygen installed. Three findings live precisely outside it — python3 missing on Windows, ENOENT when a glob directory is absent from the pinned submodule, and the hardcoded sidebars.js link.id that turns a missing submodule into an opaque Docusaurus error instead of the warning sync-external-docs.js deliberately emits. A windows-latest leg and a "submodule/doxygen unavailable" leg would cover all three. templates/*.py (231 lines) has no tests of any kind.

One thing I'd flag separately: onBrokenAnchors was relaxed from 'throw' to 'warn' in this PR, and the dead anchor it was reporting is now shipping. That is the one automated check that caught a real defect here, and the change switches it off rather than fixing the upstream heading. I'd rather see the heading fixed and throw kept — or the leniency scoped to the generated tree only.

None of this needs to block the merge; the feature works and the build is green. But the transforms are regex-based rewriting of third-party generator output, which is exactly the code that breaks silently the next time doxygen2docusaurus or upstream Doxygen changes its markup. Without unit tests, every such change reopens this review by hand.

[mbegin-robotiq]

Approving.

The feature works, the build is green, and none of the findings from my pass
block the merge — the two I'd most like to see land before this goes out are
moveDetailedDescriptionToTop (the Members index ending up at the bottom of
every class page) and the folder-guide titles, both already on Eric's threads
with a failing test attached.

The test-coverage ask in the comment above stands as follow-up work rather than
a condition on this PR.