In order to make the arrow binding hint's dashed stub render cleanly
across markers, zoom levels, and arc paths, this PR fixes the
cross-marker offset, replaces the ad hoc dash math with
`getPerfectDashProps`, computes the arc stub's length along the arc
rather than as straight-line distance, and falls back to a solid stub
below a minimum zoom.

The stub was offset from the handle by `crossSize / 2`, but the cross is
drawn from `(-half, -half)` to `(half, half)`, so its leg endpoints sit
at `(crossSize / 2) * sqrt(2)` from the handle. The stub ended inside
the cross's footprint, which read as having no offset at all next to the
dot case (where the offset matches the dot's full radius). The arc
branch also used the chord distance to size dashes, which produced
uneven dash lengths along curved stubs.

### Change type

- [x] `bugfix`

### Test plan

1. Open the examples app and draw an arrow.
2. Bind one end of the arrow to a shape and drag the other end so that
there is a visible gap between the bound point and the user's intended
position.
3. Confirm the dashed stub stops short of the precision cross marker,
with the same visual gap as the dot marker case.
4. Try the same on an arc-shaped arrow and confirm dashes are evenly
spaced along the arc.
5. Zoom out below 20% and confirm the stub renders as a solid line
instead of unreadable dashes.

### Release notes

- Fix the arrow binding hint's dashed stub overlapping the precision
cross marker, dash spacing on arc-shaped stubs, and unreadable dashes at
low zoom.

### API changes

- Added `dashedMinZoom` option to `ArrowBindingHintOverlayUtil` (default
`0.2`); below this zoom the stub renders as a solid line.

### Code changes

| Section         | LOC change |
| --------------- | ---------- |
| Core code       | +42 / -7   |
| Automated files | +1 / -0    |

In order to make overlay display customization use the same theme-aware
pattern as shape display values, this PR adds overlay display value
resolution and applies it to the brush overlay. It also includes a
focused refactor of the default canvas overlay utilities: reducing
redundant work, simplifying helper visibility, and tightening rendering
logic without changing user-facing overlay behavior. Relates to #8314.

### Change type

- [x] `api`

### Test plan

1. `cd packages/tldraw && yarn test run src/test/overlays`
2. `yarn build-types`
3. `cd packages/tldraw && yarn build-api`
4. `cd packages/editor && yarn build-api`
5. `yarn lint-current`

- [x] Unit tests
- [ ] End to end tests

### Release notes

- Add theme-aware display value customization for brush overlays.

### API changes

- Added `getOverlayDisplayValues()` in `@tldraw/editor` for resolving
overlay display values from themes and custom overrides.
- Added `OverlayOptionsWithDisplayValues` in `@tldraw/editor`.
- Added `BrushOverlayUtilDisplayValues` and `BrushOverlayUtilOptions` in
`tldraw`.
- Changed `BrushOverlayUtil.options` to use display value callbacks
instead of a direct `lineWidth`.
- Made undocumented internal helper methods on arrow hint and
collaborator hint overlays private.

### Code changes

| Section         | LOC change |
| --------------- | ---------- |
| Core code       | +272 / -112 |
| Tests           | +97 / -0   |
| Automated files | +32 / -17  |

…8681)

On a fresh `yarn dev` boot, `apps/dotcom/zero-cache` runs `docker-up`,
`migrate --signal-success`, `bundle-schema:watch`, and `zero-server`
concurrently. When Postgres comes up faster than migrations apply,
`zero-server` connects before migration `016_zero_publication.sql` has
created the `zero_data` publication and crashes with `Error: Unknown or
invalid publications. Specified: [zero_data]. Found: []`. Nodemon then
parks (`app crashed - waiting for file changes before starting...`) and
zero-cache stays dead even after migrations finish, because nothing
touches `.schema.js`.

This PR mirrors the existing `apps/dotcom/client/wait-for-postgres.sh`
pattern: a new `apps/dotcom/zero-cache/wait-for-migrations.sh` polls the
migrate process's HTTP signal on `localhost:7654` until it returns `ok`.
The `zero-server` script now waits on it before launching nodemon, so
initial sync only runs after migrations have been applied. Subsequent
nodemon reloads (when `.schema.js` rebuilds) are effectively instant
since the signal endpoint stays up for the lifetime of the dev session.

### Change type

- [x] `bugfix`

### Test plan

1. `cd apps/dotcom/zero-cache && yarn clean` (removes the docker
volume).
2. `yarn dev` from the repo root.
3. `zero-cache` should print `Waiting for migrations to finish...` a
couple of times, then `Migrations are ready!`, then boot cleanly with no
`Unknown or invalid publications` error.
4. Edit `packages/dotcom-shared/src/tlaSchema.ts`; `bundle-schema:watch`
rebuilds `.schema.js`, nodemon restarts `zero-cache-dev`, and the wait
passes instantly.

### Release notes

- Internal dev tooling only; no user-facing change.

Made with [Cursor](https://cursor.com)