main's tests pass again: the #notesPill fade rules move from src/ui/notes.css into viewer.html's <style> #523

Both #notesPill fade rules now sit in Software/so101/src/viewer.html's <style>, next to the pill's own rule, so stop-layout.test.ts:172 passes again. The fade works as before: the pill has transition: opacity .4s ease, and #notesPill.fading { opacity: 0; } sits right after it. src/ui/notes.css no longer mentions notesPill.

The existing assertion is unchanged; it was right. I added one test next to it (the pill fades out on the page's own rules…) that checks the page's own rules carry the 0.4 s transition and the .fading opacity 0. Without it, a later move could quietly drop the fade.

Test results:

• bun test src/stop-layout.test.ts src/ui/notes.test.ts: 14 pass, 0 fail.
• Whole suite: 883 pass, 1 skip, 2 fail. Both failures are in src/tuning-endpoint.test.ts, which came in with #506 after this issue was written: "a run is refused while someone drives, and nothing is written" and "a real sweep through the stream ends with a result…". They fail every time when that file runs alone in this sandbox, and they don't use anything this pull changes. They're timing-sensitive (60 ms watchdog, sleep-based waits), so this pull leaves them alone. If the forge's check fails them too, they need their own issue against #506's tuning run.

Not done: scripts/design-lint.ts doesn't exist at the repository root, so there was no lint to run. forge.json is untouched.

To try it: open the preview, open the notes pill and let it fade. It should go to opacity 0 over 0.4 s and never show unstyled while notes.css loads.

🤖 Generated with Claude Code

Closes #512

Both #notesPill fade rules now sit in Software/so101/src/viewer.html's <style>, next to the pill's own rule, so stop-layout.test.ts:172 passes again. The fade works as before: the pill has transition: opacity .4s ease, and #notesPill.fading { opacity: 0; } sits right after it. src/ui/notes.css no longer mentions notesPill.

The existing assertion is unchanged; it was right. I added one test next to it (the pill fades out on the page's own rules…) that checks the page's own rules carry the 0.4 s transition and the .fading opacity 0. Without it, a later move could quietly drop the fade.

Test results:

• bun test src/stop-layout.test.ts src/ui/notes.test.ts: 14 pass, 0 fail.
• Whole suite: 883 pass, 1 skip, 2 fail. Both failures are in src/tuning-endpoint.test.ts, which came in with #506 after this issue was written: "a run is refused while someone drives, and nothing is written" and "a real sweep through the stream ends with a result…". They fail every time when that file runs alone in this sandbox, and they don't use anything this pull changes. They're timing-sensitive (60 ms watchdog, sleep-based waits), so this pull leaves them alone. If the forge's check fails them too, they need their own issue against #506's tuning run.

Not done: scripts/design-lint.ts doesn't exist at the repository root, so there was no lint to run. forge.json is untouched.

To try it: open the preview, open the notes pill and let it fade. It should go to opacity 0 over 0.4 s and never show unstyled while notes.css loads.

🤖 Generated with Claude Code

Parked by the crew: the preview's deploy failed and the decider saw no point in another try