BCF export

[Ghesselink]

Add experimental BCF 2.1 export of validation outcomes

• GET /api/v1/validationrequest/<id>/bcf (token auth) + BFF equivalent for
  the UI; generated on-the-fly, no storage, no migrations. Download buttons on
  the report page and dashboard.
• One topic per ERROR/WARNING outcome, grouped per rule, capped at 10 per rule
  (cap noted in the description). Allowlisted outcomes are excluded, same as
  the report UI.
• Element linkage via GlobalId; entities without one (e.g. polyloops) resolve
  to the nearest parent IfcProduct via inverse relations. Viewpoints select the
  element in the viewer; each ships a ~2KB placeholder snapshot (see design
  question 4).
• Uses IfcOpenShell's bcf-client (installed with --no-deps).
  .

Design thoughts / open questions

We checked how the existing ecosystem handles these; references inline.

1. Validation outcome caps Capping by count can silently drop a different
   11th occurrence. How to group? e.g. content
   normalization per rule, a cap within groups, or something else.
2. Element reference in the title. Viewers truncate descriptions;
   ifctester puts IfcClass - Name - reason - GlobalId in the topic title,
   which survives truncation. Proposal: do the same here.
3. Non-product components. ifctester gives viewpoints to placeable
   elements only. Here we additionally try the parent-walk first, then fall back to
   a topic without viewpoint. Spec allows any IfcGuid
   (BCF-XML#182).
4. Snapshots. The spec marks snapshots optional, see also [Question] Are snapshots mandatory for a viewpoint in BCF 2.1? BCF-XML#399
5. Large models. The parent-walk opens the IFC (lazy, once per download;
   ~0.07s/MB, ~12x file size in RAM). Structural fix: the RocksDB store from
   #228.