PdfReaderToolbar class

Ready-made row combining bookmark / notes / highlights / search / jump-to-page / appearance / reading-settings actions. Drop into a host app's own AppBar.actions when using showAppBar: false.

Production-pass fix — parity with the plugin's own app bar

The plugin's built-in app bar (_AppBarWithSearch in pdf_reading_tracker_viewer.dart) was decluttered to show only Search · Notes · Highlights · Bookmarks inline, with Jump to page · Appearance · Reading settings moved into a single overflow menu — see that file's audit note. This widget previously rendered all seven actions inline, which meant a host app using the default PdfReaderToolbar presented a visibly different (more crowded) toolbar than the plugin's own chrome for the exact same feature set — a showAppBar:false host and a showAppBar:true reader no longer looked or behaved the same.

This now mirrors the plugin's layout exactly: Search, Notes, Highlights, Bookmarks stay as individual always-visible icons; Jump to page, Appearance, and Reading settings are grouped into one PopupMenuButton (icon: Icons.more_vert_rounded), in the same order, with the same icons/labels the plugin's overflow menu uses. No new controllers or state were introduced — every action still forwards to the exact same PdfReaderActions method it always called; only the arrangement of existing buttons changed. The show* flags keep their original meaning (whether an action is available at all); for showJumpToPage / showAppearance / showReadingSettings they now control whether that action's entry inside the overflow menu appears, and the overflow button itself is omitted entirely if none of the three are enabled.

Reader-UX redesign pass — icon spacing / touch targets

Icons are now separated with a small explicit gap (rather than relying solely on IconButton's own internal padding) and each gets a rounded-rectangle Material 3 tap target via IconButton.styleFrom, matching the plugin's own _AppBarWithSearch treatment — so a host toolbar built from these widgets looks like the same "premium reader" family as the plugin's built-in chrome, not a visually distinct row of default Material icons. No callback, ordering, or show* flag semantics changed.

Host apps that prefer a fully custom arrangement can still compose BookmarkButton, NotesButton, HighlightsButton, SearchButton, JumpToPageButton, AppearanceButton, and ReadingSettingsButton directly instead of using this composite widget.