feat(analytics): add Plausible custom-event markings for six goals

Mark the six conversion goals on the self-hosted Plausible instance so the
events match the goals to be registered in Plausible. Event names verbatim:
Trial, FAQ, Buy, Custom Quote, search posts, Project Plan.

CSS-class markings (work without JS logic, on the clickable element):
- FAQ  -> index/de/es index .faq-card; odoo-hosting-2027 + odoo-community-upgrade
          (de/es twins) and australia <summary>; support.html .faq-question
- Buy  -> index/de/es index .btn-buy anchors; australia + bootcamp native
          post_basket submit buttons (forms stay native POST)

JS call markings in script.js (loaded by index, de/index, es/index):
- Trial        on the successful trial-form POST (.then branch)
- Custom Quote on the successful custom-quote POST (.then branch)
- Project Plan on the successful business-wizard submit
- search posts on the FIRST input of #blogSearch only (guard flag, one per
  pageview, not on every keystroke, not on #ocaSearch)

Nothing fires on page load; the 'Start the free trial' anchors that only
scroll to #trialCard are deliberately not tagged. One goal per topic across
all languages, no language suffix. No visual, behavioural or request change.

odoo-community-upgrade.html

@@ -874,7 +874,7 @@ sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
         <h2 class="section-title">Questions about upgrading</h2>
         <div class="cmp-faq-grid">
           <details class="cmp-faq">
-            <summary>Is an upgrade the same as an update?</summary>
+            <summary class="plausible-event-name=FAQ">Is an upgrade the same as an update?</summary>
             <div class="cmp-a">
               <p>
                 No. An update gives you the newest revision of the software you already run. An upgrade moves
@@ -885,7 +885,7 @@ sudo -u postgres pg_restore -d &lt;DB_NEW&gt; /path/backup/&lt;DB&gt;.dump
             </div>
           </details>
           <details class="cmp-faq">
-            <summary>Can we upgrade straight from Odoo 14 to Odoo 20?</summary>
+            <summary class="plausible-event-name=FAQ">Can we upgrade straight from Odoo 14 to Odoo 20?</summary>
             <div class="cmp-a">
               <p>
                 No. It is one major version at a time: 14 → 15 → 16 → 17 → 18 → 19 → 20. Skipping a version is
@@ -896,7 +896,7 @@ sudo -u postgres pg_restore -d &lt;DB_NEW&gt; /path/backup/&lt;DB&gt;.dump
             </div>
           </details>
           <details class="cmp-faq">
-            <summary>What happens to my history — the invoices, the payments, the attachments?</summary>
+            <summary class="plausible-event-name=FAQ">What happens to my history — the invoices, the payments, the attachments?</summary>
             <div class="cmp-a">
               <p>
                 That is the right question to ask, and the honest answer is that it depends on the route. The
@@ -911,7 +911,7 @@ sudo -u postgres pg_restore -d &lt;DB_NEW&gt; /path/backup/&lt;DB&gt;.dump
             </div>
           </details>
           <details class="cmp-faq">
-            <summary>Will my custom modules still work?</summary>
+            <summary class="plausible-event-name=FAQ">Will my custom modules still work?</summary>
             <div class="cmp-a">
               <p>
                 Not by themselves. A module written for your business has to have its code brought up to the
@@ -924,7 +924,7 @@ sudo -u postgres pg_restore -d &lt;DB_NEW&gt; /path/backup/&lt;DB&gt;.dump
             </div>
           </details>
           <details class="cmp-faq">
-            <summary>What does it cost, and how long does it take?</summary>
+            <summary class="plausible-event-name=FAQ">What does it cost, and how long does it take?</summary>
             <div class="cmp-a">
               <p>
                 We publish no price and no duration for the upgrade service, and we are not going to invent one
@@ -936,7 +936,7 @@ sudo -u postgres pg_restore -d &lt;DB_NEW&gt; /path/backup/&lt;DB&gt;.dump
             </div>
           </details>
           <details class="cmp-faq">
-            <summary>Do I need a developer?</summary>
+            <summary class="plausible-event-name=FAQ">Do I need a developer?</summary>
             <div class="cmp-a">
               <p>
                 To run the commands in the technical section, yes — or someone comfortable in a terminal with
@@ -946,7 +946,7 @@ sudo -u postgres pg_restore -d &lt;DB_NEW&gt; /path/backup/&lt;DB&gt;.dump
             </div>
           </details>
           <details class="cmp-faq">
-            <summary>Can I look at the upgraded system before going live?</summary>
+            <summary class="plausible-event-name=FAQ">Can I look at the upgraded system before going live?</summary>
             <div class="cmp-a">
               <p>
                 Yes, and you should. Whoever does the work migrates a copy first — that is the first rule of the
@@ -958,7 +958,7 @@ sudo -u postgres pg_restore -d &lt;DB_NEW&gt; /path/backup/&lt;DB&gt;.dump
             </div>
           </details>
           <details class="cmp-faq">
-            <summary>We are hosted somewhere else. Can you still upgrade us?</summary>
+            <summary class="plausible-event-name=FAQ">We are hosted somewhere else. Can you still upgrade us?</summary>
             <div class="cmp-a">
               <p>
                 Yes, that is exactly what our migration service is for. You open a support ticket, we send you a