Full tbd sync blocked by one failing tracker item says nothing about the updates behind it, and does not accept --yes

## Summary

When one item fails the tracker surface, a full `tbd sync` says nothing about the other pending updates behind it, and the large-change threshold that then blocks them is only discoverable through the narrower `tbd integration sync --push`, which `tbd sync` does not accept `--yes` for.

## What happened

```
$ tbd sync
⚠ Integration sync failed; continuing with git sync. Run `tbd integration sync` for details.
(1 integration item operation(s) failed: linear/p-aaaa: duplicate_of: … ) # the #267 case
$ tbd integration sync --push
Error: This run would make a large change: 174 updates (threshold 40).
Re-run with --yes to confirm, narrow the set with --bead or --limit, or preview it first with --dry-run.
$ tbd integration sync --push --yes
linear: created 0, updated 173, skipped 6, fields not pushed 5, failed 1
```

The first command gave no hint that 173 updates were waiting, nor whether it had skipped them for size or because of the failing item. The threshold itself is a sensible guard.

## Suggested change

- In the full-sync summary, print the pending count for each tracker surface and, when a run is blocked, whether it was the threshold or a failing item (and which).
- Accept `--yes` on `tbd sync` so the operator does not have to switch commands to proceed.

Environment: tbd 0.8.1, Node v24.19.0, macOS 26 (Darwin 25.5), Linear integration enabled. Repository scale when observed: 7,156 beads, 137 open epics, 171 tracker links, about 110 plan specs in `active/`.

Trace the `tbd sync` and `tbd integration sync --push` command entry points, starting with how integration failures and large-change thresholds are summarized. Implement pending counts and the blocking reason in the full-sync output, and accept `--yes` on `tbd sync`; done means operators can see why updates were blocked and proceed without switching commands.

Written by the indexing model from the issue text.