Challenge 1: Wire Up the web-vitals Library — Possible Solution
====================================================================

import { onLCP, onINP, onCLS } from "web-vitals";

function logMetric(metric) {
  console.log(`${metric.name}: ${metric.value}`);
}

onLCP(logMetric);
onINP(logMetric);
onCLS(logMetric);

WHY THIS WORKS
--------------
- Each of onLCP, onINP, and onCLS registers a callback that the library
  invokes automatically once that specific metric has been measured and
  finalized for the current page — this mirrors the chapter's own
  sendToAnalytics example structurally, just swapping out the
  destination (console.log instead of navigator.sendBeacon).
- Using ONE shared logMetric function for all three calls (rather than
  three separate, duplicated callback functions) works because every
  Core Web Vitals metric object the library passes to a callback shares
  the same basic shape — a "name" field (e.g. "LCP", "INP", or "CLS")
  and a "value" field — so a single generic logger can correctly handle
  whichever specific metric triggers it.
- metric.name and metric.value are read directly off whatever metric
  object the library provides to the callback — this is the same
  destructuring/property-access pattern implied by the chapter's own
  example, which passes the entire metric object to
  JSON.stringify(metric) for sending; here it's read individually
  instead, for a more readable console log line.
- This satisfies the "capture all three, log instead of send" goal
  precisely: nothing is sent over the network (no sendBeacon or fetch
  call), but all three metrics are still genuinely captured and
  reported the moment each becomes available, exactly matching how
  real field-data collection would work if a destination were wired up
  afterward.