bridges for attempts and visits

`fact_attempts` and `fact_visits` have arrays in their output. Looks like the better way is to use bridge tables.

---
Bridge Tables
A helper table that resolves many-to-many relationships between a fact table and a dimension.
Why it exists:

Dimensions should be one-to-many with facts (one product per sale)
But sometimes facts have many dimensions of the same type (e.g., one order has many products, or one product has multiple colors)
Bridge tables enable many-to-many relationships while maintaining the star schema

Example - Orders with Multiple Products:
Without bridge table (denormalized fact):
OrderKey | ProductKey | Quantity | Amount
1 | 100 | 2 | 49.98
1 | 101 | 1 | 29.99 ← Same order, multiple rows (violates grain)
With bridge table:
Order_Product Bridge
├── OrderKey | ProductKey | Quantity | Amount | Weight
│ 1 | 100 | 2 | 49.98 | 0.5
│ 1 | 101 | 1 | 29.99 | 0.5

Orders Fact (grain: one row per order)
├── OrderKey | CustomerKey | DateKey | TotalAmount
│ 1 | 5 | 120 | 79.97
Common use cases:

Multiple products per order
Multiple colors/sizes per product variant
Multiple physicians per patient visit
Multiple technicians per service call

Start by locating the fact_attempts and fact_visits model definitions and inspecting how their arrays are produced. Review the existing fact-table grain and determine the bridge-table structure needed for each relationship; done means the arrays are replaced by appropriate bridges without breaking the fact outputs or their relationships.

Written by the indexing model from the issue text.