Add TypeScript for type safety in JavaScript codebase

## Summary

Adopt TypeScript for the JavaScript codebase to improve type safety, IDE support, and catch errors at compile time. Now that we have a proper build system with webpack, TypeScript integration is straightforward.

## Benefits

1. **Catch errors early** - Type mismatches caught at build time, not runtime
2. **Better IDE support** - Autocomplete, refactoring, go-to-definition
3. **Self-documenting** - Types serve as inline documentation
4. **Safer refactoring** - Compiler catches breaking changes
5. **Better React props** - Replace PropTypes with interfaces (smaller bundle)

## Example

```typescript
// Before: JavaScript with PropTypes
const Entry = ({ id, content, authors }) => { /* ... */ };

Entry.propTypes = {
id: PropTypes.number.isRequired,
content: PropTypes.string.isRequired,
authors: PropTypes.arrayOf(PropTypes.object),
};

// After: TypeScript
interface Author {
id: number;
name: string;
avatar?: string;
}

interface EntryProps {
id: number;
content: string;
authors: Author[];
}

const Entry: React.FC = ({ id, content, authors }) => { /* ... */ };
```

## Migration Strategy

### Phase 1: Setup (1 day)
- Install TypeScript: `npm install -D typescript @types/react @types/react-dom`
- Configure `tsconfig.json` with `allowJs: true` for gradual adoption
- Update webpack to handle `.ts`/`.tsx` files

### Phase 2: Type Definitions (1 week)
- Create types for Redux state shape
- Create types for API responses
- Create types for WordPress globals (`window.liveblog_settings`)

### Phase 3: Gradual Migration
- Rename files `.js` → `.tsx` one at a time
- Start with utility functions (low risk)
- Then reducers and actions
- Then components (simpler first)
- Enable stricter options incrementally

### Phase 4: Cleanup
- Remove `prop-types` dependency
- Enable `strict: true` in tsconfig
- Add type coverage reporting to CI

## Considerations

1. **Learning curve** - Team needs TypeScript familiarity
2. **Build time** - Slightly slower builds (minimal with modern tooling)
3. **Third-party types** - Most libraries have types, but some may need `@types/*` packages
4. **Gradual adoption** - Can coexist with JavaScript during migration

## Configuration

```json
// tsconfig.json
{
"compilerOptions": {
"target": "ES2020",
"module": "ESNext",
"lib": ["ES2020", "DOM"],
"jsx": "react-jsx",
"allowJs": true,
"checkJs": false,
"strict": false,
"esModuleInterop": true,
"skipLibCheck": true,
"outDir": "./build",
"rootDir": "./src"
},
"include": ["src/**/*"],
"exclude": ["node_modules", "build"]
}
```

## Success Metrics

- [ ] TypeScript configured and building
- [ ] Core types defined (Entry, Author, Config, State)
- [ ] New code written in TypeScript
- [ ] 50%+ of existing code migrated
- [ ] PropTypes dependency removed

Start by reviewing the existing webpack configuration and the JavaScript sources under src/**/* to determine the current build and migration boundaries. Use the proposed tsconfig.json settings and migration phases as the checklist; done would require TypeScript building, core types, migrated code, strict configuration, and removal of PropTypes as described.

Written by the indexing model from the issue text.