fix(editor): alinhamento seleção/Enter — paridade de layout textarea×overlay

Dois defeitos de geometria entre o textarea transparente (desenha caret e
seleção) e o overlay #hl (desenha o texto visível):

1. Largura: no Windows/Chrome o scrollbar clássico do textarea (~15-17px)
   reduz sua área de texto; o overlay (overflow:hidden) não — cada linha
   quebrava em colunas diferentes e a seleção ficava com 'buracos' e
   deslocamento progressivo. Agora: scrollbar-gutter:stable no textarea
   (largura constante, sem saltar ao cruzar 1 tela) + --sbw medido por JS
   espelhado no padding-right do overlay a cada render.
2. Negrito sintetizado: tk-h/tk-strong/tk-mark usavam font-weight 700; sem
   face bold na fonte monoespaçada, o Chrome alonga os glifos (~1-2px/char)
   e o overlay acumulava offset por linha (visível no print: seleção parava
   no fim do trecho negrito). font-synthesis:none no overlay + pseudo-negrito
   por text-shadow (.35px) — peso visual preservado, avanço idêntico.

Também: renderEditorVisual reassincroniza scrollTop/scrollLeft de hl/gutter
após replaceChildren (antes o Enter em nota longa zerava o scroll do overlay
— 'Enter não atualiza a visualização').

Verificado headless: com scrollbar clássico simulado (15px), largura de texto
textarea==overlay (1078==1078), seleção contínua até o fim correto da linha
quebrada; Enter com doc rolado mantém ta/hl/gutter em 5000; wysiwyg/preview
sem regressão. sw v14.

web/sw.js

@@ -1,7 +1,7 @@
 /* Service Worker do Notas — caches versionados.
  * BUMP de CACHE em todo deploy que mude shell/assets (o activate limpa os antigos).
  */
-const CACHE = 'notas-shell-v13';
+const CACHE = 'notas-shell-v14';
 const SHELL = [
   '/',
   '/css/app.css',