Fix/form labels accessibility

[Benedict315]

Description

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📚 Documentation update
• 🔧 Refactoring (no functional changes)
• ⚡ Performance improvement
• 🧪 Test addition or update

Related Issues

Closes #

Changes Made

Testing

Test Coverage

• Unit tests added/updated
• Integration tests added/updated
• Manual testing performed

Test Steps

Breaking Changes

Breaking Changes:

Migration Guide:

Screenshots/Demo

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published
• I have checked for breaking changes and documented them if applicable

Additional Notes

closes #632

[ogazboiz]

the a11y part is real and good, dashboard-view.tsx gets proper htmlFor/id pairing on the template name, recipient, token, amount, dates, cadence and note inputs. but this pr is effectively #972 plus that a11y work: it carries the same 410 deprecated-handlers, the same ci.yml:98 @vitest/coverage-v8 install removal (which risks re-breaking the coverage job), and the same Dockerfile/worker newline churn. two asks:

1. drop the ci.yml coverage-v8 install removal (same regression risk i flagged on #972) and the Dockerfile/worker churn.
2. this and #972 overlap, pick one lane, if you want the a11y work, take this one (stripped) and close #972 as redundant.

the a11y changes are mergeable, it's the bundled ci change that blocks it.