Frontend: choose between following and pinning in the share dialog

### Task Summary

Part of #7828. **The first task in the series a user can see.** The share dialog said whether a
workflow was public and nothing about which copy the public was getting; with pinning that is a
choice, so the dialog carries it.

- **A two-option control** under the Public tile. *Follow latest* is the default and is exactly
what publishing does today — the public sees the author's latest, updated on every save.
*Pinned* freezes the version the author has now; later edits stay private until they pin again.
- **While a pin is holding edits back**, the panel says so, names the pinned version by the date
it went public, and offers *Update to current* — the only way those edits reach the public.
- **Private workflows show none of this**, and a user without write access cannot reach it.
- **The panel re-reads when a save lands**, not when the dialog is opened:
`WorkflowPersistService` now emits on persist, rename and re-description, which is what makes
"your edits are not public yet" appear as soon as the autosave does. Publishing returns the
state it produced, so the panel does not have to ask again.
- Forcing a save when the dialog opens was tried and reverted: the canvas is not always the
workflow — it is empty while one loads, and stays empty if the collaborative model never
arrives — so that save could write the emptiness over every operator the workflow had.

Covered by `share-access.component.spec.ts` and `workflow-persist.service.spec.ts`: the three
states and their wording, the control switching between them, pinning and unpinning through the
service, the panel re-reading when a save lands, the panel staying away on a private workflow
and for a user without write access, and the dialog's existing access list untouched.

### Task Type

- [ ] Refactor / Cleanup
- [ ] DevOps / Deployment / CI
- [ ] Testing / QA
- [ ] Documentation
- [ ] Performance
- [x] Other