Integration sync reports a parent overwrite after the write, and an unmapped assignee without naming the assignee or the fix

Two reporting gaps in `tbd integration sync` that agents cannot act on: a tracker-side edit is reported only after it is overwritten, and an unmapped assignee is reported without naming the assignee or the remedy.

**Environment:** tbd 0.9.0, Linear provider, team FIN, one repo, run of 2026-09-17.

Both came out of one run:

```
linear: push 85, comments out 22, create 1, skipped 5, fields not pushed 1, warnings 5
```

## 1. A parent push overwrites a tracker-side edit, and says so afterwards

16 lines of this form, one per bead:

```
~ trading-yadz: parent push overwrote an edit
~ trading-6ma5: parent push overwrote an edit
```

The write has already happened when the line prints. `--dry-run --explain` does show the pair beforehand (`rule: local`, `remote=null`, `base=`), but only if the operator thinks to look, and the bulk-change threshold that guards volume says nothing about conflicts.

A tracker-side edit is a human's work. Overwriting it silently, then reporting it in the past tense, is the one case where the mirror should ask.

**Requests, in order of usefulness:**
1. Count tracker-side edits in a pre-flight and require confirmation for them, the way the bulk threshold already requires `--yes` for volume. A run with 85 pushes and 16 overwrites should not be one decision.
2. `--on-conflict=local|skip|fail` so an unattended agent can choose "skip and report" and leave the human's edit alone.
3. Print the value that was replaced, not just that a replacement happened, so it can be restored without opening the tracker's history.

## 2. An unmapped assignee names the item but not the person or the fix

5 warnings, all of this form:

```
! FIN-481: Linear assignee is not present in identity.user_map; assignee synchronization skipped.
```

The message names the tracker item, which is the one thing the operator does not need: the missing piece is who the unmapped assignee is, and what to add where. As written, an agent can only report the warning verbatim, so the tail of 5 warnings persists run after run with nobody able to clear it.

A sibling line has the same shape:

```
- trading-ztop: assignee push skipped; unsupported by the provider; left divergent
```

"Left divergent" means every later run repeats it, with no way to accept the divergence as permanent.

**Requests:**
1. Name the unmapped assignee (tracker display name, and email if the provider returns one) and give the command that adds the mapping.
2. For a field the provider does not support, say which field and provider, and offer a way to record that divergence as accepted so it stops being reported as a problem.

## Related

- #276, the bulk-threshold message and `--yes` on `tbd sync`
- #272, deep beads skipped by `max_nesting`
- #265, sync convergence

Both of these are reporting problems rather than data problems: the sync did what it was configured to do. What is missing is the chance to review the overwrite first, and enough detail in the warning to end it.

Start at the `tbd integration sync` entry point and compare normal runs with `--dry-run --explain`; review the bulk-threshold behavior referenced by #276. Done means tracker-side overwrites are reviewed before writing, conflict handling supports the requested unattended modes, and assignee or unsupported-field warnings identify the remedy and an accepted-divergence path.

Written by the indexing model from the issue text.