Save + View pulled out of their own row and into the chrome bar, opposite the title. Featured image (when supported) sits inline with them as a small 36px chip.
Two cases: post type supports featured image, and doesn't. Each shown at desktop and 390px mobile. Mobile gets a second row for actions when there's a featured image, to avoid crowding.
Thumb sits left of the View + Save pair. Clicking the thumb opens the media picker (unchanged). Mobile stacks actions below the title to give them breathing room.
Same chrome, no thumb. Mobile keeps everything on one line because there's one less element to fit.
If you want to avoid stacking. Tight but possible: thumb shrinks to 32px, Save uses just "Save", title truncates. Risk: on narrow iPhones title gets cut aggressively.
My take: A (stack on mobile) is safer — one long service name doesn't force a cramped chrome. The extra row costs ~44px of vertical space but keeps everything legible. C works for short titles but will feel cramped on real cafe menu items ("Flat white with oat milk", "Gluten-free banana bread").
You want the slug to auto-update when titles change significantly, without showing a slug field to owners. Clean way: on the REST save, if the title changes and the current slug looks auto-generated from the old title (i.e. it matches sanitize_title(old_title)), regenerate the slug. If the old slug was hand-customised, preserve it.
That gives owners "rename freely" behaviour for fresh pages while respecting admin-set slugs on curated ones. No UI exposure needed. I'd show the current URL as read-only muted text below the chrome (like the cafe.makedev.com.au / services / test-service line in Variant A) so owners see the consequence of their rename without feeling like they're in a URL editor.
Go with Variant A + B (stack on mobile when there's a featured image). Add the read-only URL line below the chrome. Auto-regenerate slug on title change if the slug was auto-generated. No settings cog, no hidden details panel — featured image earns its visibility by being a single 36px chip.
Flag: if a post type adds another thing (status, taxonomy, etc.) that also wants top-chrome space, we'll hit the limit fast. When that comes up, revisit with either a cog pattern or the inline "Page settings" collapse I proposed earlier.