Remove extra tags

src/content/work/perfect-postcode-rust-property-server.md

@@ -11,7 +11,6 @@ links:
     url: https://perfect-postcode.co.uk
 article:
   tags: ['systems', 'web', 'tools']
-  role: Server architect and operator
   stack:
     [
       'Rust',
@@ -28,7 +27,6 @@ article:
     ]
   scale: ~25M historical properties, ~2.5M postcodes, ~150 numeric features per row, all in RAM on a single VM
   outcome: A single-binary UK property-intelligence service with sub-100ms hexagon aggregations under filter
-  audience: technical
   media:
     - type: image
       src: ./_assets/perfect-postcode.jpg
@@ -36,10 +34,7 @@ article:
       caption: A normal user pan triggers a hexagon aggregation under filter. The hot path holds itself to three integer compares per row.
 project:
   title: Perfect Postcode
-  description: A UK property-intelligence map. ~25M historical transactions, ~150 features per row, all u16-quantised in RAM, served from a single Rust binary.
   selected: true
-  thumbnail:
-    alt: The Perfect Postcode dashboard with active filters on property type, price, transit time, and crime, showing a Manchester map with matching properties as a heatmap.
 ---
 
 A user told me the map felt sluggish when they dragged it across Manchester with four filters on. They were right, and it stung, because the previous version round-tripped to a database, decoded floats, and had spent its entire latency budget before it finished evaluating the first filter. The rewrite is one Rust binary that holds the entire UK property history in RAM and treats every filter as three integer compares. Everything else in this post follows from refusing to let that sluggishness come back.