refactor(handlers): convert dashboardHandlers and storageHandlers to Pattern A (named functions + registry)

[smithrashell]

Background

Handler files follow one of two patterns:

Pattern A — named functions + registry (problemHandlers, sessionHandlers, onboardingHandlers):

export function handleGetStats(request, _dependencies, sendResponse, finishRequest) { ... }

export const handlers = { 'getStats': handleGetStats };

Pattern B — logic inline in the exported object (dashboardHandlers, storageHandlers, hintHandlers, strategyHandlers):

export const handlers = {
  getStats: (request, _dependencies, sendResponse, finishRequest) => { ... }
};

Established guideline

Pattern B is appropriate for simple handlers reading from static/JSON data (hintHandlers, strategyHandlers — their simplicity is justified by their data source).

Pattern A is appropriate for complex handlers with database operations, async branching, or multi-step logic — the named function makes the logic readable as a standalone unit rather than buried in an object literal.

Files to change

• src/background/handlers/dashboardHandlers.js — ~20 handlers, several with complex async logic and conditional branching
• src/background/handlers/storageHandlers.js — ~15 handlers including diagnostic session creation and adaptive calibration operations

Benefits

• Named functions appear by name in stack traces (arrow functions in objects show as anonymous)
• Individual handlers can be imported and tested in isolation without going through the registry object
• Complex logic is scannable as discrete units, not one giant export const = {} block

Risk

Low — pure structural refactor. The exported registry object shape stays identical, no callers change, existing tests pass without modification.