Integrate baseline-status component

[schalkneethling]

Summary

• Add the official baseline-status web component dependency and serve its bundled script locally.
• Render the component on individual feature pages above the existing card grid.
• Keep the old browser support card as a graceful fallback until the custom element is defined.
• Add status-aware sizing/background treatment for the component using site CSS variables.

Validation

• Ran npm run build successfully after rebasing onto current upstream main.
• Verified generated feature pages include the local component script and feature-id attributes.
• Browser-checked representative feature pages during implementation for component upgrade/rendering and fallback hiding.

Closes #15

[schalkneethling]

@captainbrosset resolved the merge conflict.

[captainbrosset]

Sorry for the slow reply. I'm not super sold on the idea to use the component. The reason is that it uses runtime JavaScript to retrieve the Baseline status for a feature, whereas the rest of the site is (mostly) JS-free. Most importantly, each feature page contains the entire data about the feature in the HTML, created at build time. I'm very hesitant to move away from this model.

[schalkneethling]

Sorry for the slow reply. I'm not super sold on the idea to use the component. The reason is that it uses runtime JavaScript to retrieve the Baseline status for a feature, whereas the rest of the site is (mostly) JS-free. Most importantly, each feature page contains the entire data about the feature in the HTML, created at build time. I'm very hesitant to move away from this model.

Makes sense. I was basing this on the two open issues related to this.

• Consider using the new baseline-status component #15
• Add a baseline-status code snippet for each feature #31

Should we perhaps triage those and consider closing them? Also, perhaps it would be worth exploring enhancements to the current design rather than adopting the Baseline component. Thoughts?