fix(website): remove the hard-coded canonical link from Root

[IanoNjuguna]

Description

Removes the hard-coded canonical link from website/src/theme/Root.tsx:

const siteUrl = siteConfig.url;
...
<link rel="canonical" href={siteUrl} />

The reported symptom does not reproduce on the current site. Measured against production just now:

/                                        -> https://devex.intersectmbo.org/
/brand-kit/                              -> https://devex.intersectmbo.org/brand-kit/
/docs/how-to-guide/advanced/cardano-api/ -> .../docs/how-to-guide/advanced/cardano-api/

Each page canonicalizes to itself, which is the "Expected" section of #324. Docusaurus emits its own per-page <link rel="canonical"> from siteConfig.url (rendered with data-rh="true"), and it replaces the Root tag during render. Scanning the production build of the current main: 0 of 112 pages contain the form the issue quotes, and every page has exactly one canonical.

So the tag is dead code — but it is a loaded one, which is why this PR removes it rather than leaving it: if that replacement ever stops winning (a Docusaurus change, another swizzle, a different render order), every page in the site silently points at / again, which is precisely the bug described. The diff is therefore subtractive: the tag and its now-unused siteUrl, plus a comment recording why it must not come back.

Timeline for context: the hard-coded tag came in with 7cec515 ("Update Docusaurus configuration with sitemap settings and metadata enhancements"), before the SEO/metadata work in #138 gave the site correct per-page canonicals. The issue was most likely written from reading the source, which is fair — the line was and is visible there.

This PR deliberately does not add a canonical implementation of its own: doing so would produce two rel="canonical" tags per page, which is worse than one correct one.

Fixes #324

Type of Change

• Bug fix (non-breaking change which fixes an issue) — removes code whose only possible effect is the reported bug
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

Testing

• I have tested these changes locally
• I have checked for broken links — build runs with onBrokenLinks: "throw" and onBrokenAnchors: "throw", and passes
• Code examples have been tested — n/a

tsc --noEmit passes. Production build passes. Full build-output scan after the change:

pages                        : 112
without any canonical        : 0
with more than one canonical : 0
canonical == site root       : 1   (the homepage — correct)
canonical == own path        : 97
canonical != own path        : 15  (all client-redirect stubs, see below)

The 15 differing pages canonicalize to their redirect target, which is correct behaviour for a redirect stub — e.g. /docs/working-group/q2-2026/sessions/18-ai-dev-workflow/session-notes/ → .../18-cardano-ai-dev-workflow/session-notes/, and /docs/how-to-guide/beginner/howtocreateaddress/ → .../beginner/address/.

Before/after comparison is behaviour-identical, which is the point of the exercise: removing the tag changes nothing that crawlers see today, it removes the path back to the broken state.

Notes for review

• Companion observations found while scanning every page, both pre-existing and out of scope here:
  • 404.html carries rel="canonical" pointing at https://devex.intersectmbo.org/404.html/ — a nonsense URL (trailingSlash: true appending a slash to a file). Harmless in practice since a 404 should not be indexed, but worth a separate look if you want it clean.
  • The redirect stubs at /docs/working-group/q2-2026/sessions/18-ai-dev-workflow/... and 19-…/20-… exist because of the Q2 session renumbering; nothing broken, just noted.
• No SEO metadata was added or removed: the og:* and twitter:* tags in the same <Head> are untouched.

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my changes
• I have made corresponding changes to the documentation — n/a
• My changes generate no new warnings