fix(usage): replace inline casts with typeof guards in TUI renderer

[oldschoola]

Problem

The TUI usage renderer (command-controller.ts) used as string | undefined inline casts to read email/accountId/projectId/planType from UsageReport.metadata (Record<string, unknown>). These casts fabricated the type without runtime validation, violating the ts-no-inline-cast-access project rule.

Changes

Replaced all inline casts with typeof guards in 4 locations:

• formatAccountLabel — limit + report identity resolution
• formatUnlimitedReportLabel — report-only identity resolution
• resetAccountLines label — saved-reset credits display
• unlimitedReports tier — plan type suffix

Behavioral improvement

Empty-string metadata values ("") previously passed through the ?? chain and were displayed as the account label. With typeof guards, empty strings are falsy and fall through to the next fallback (scope.accountId, scope.projectId, or "account N").

This matches the pattern already used in the ACP path (usage-report.ts:formatUsageReportAccount).

Tests

• bun check passes (all 16 packages)
• All usage rendering tests pass (18/18)

[roboomp]

Rank: P1. Tight two-file fix and the unsafe casts are gone, but formatAccountLabel currently drops valid scoped fallbacks when metadata is "" or non-string.
One blocking inline finding on that fallback order; existing usage tests did not cover this TUI renderer edge. I attempted bun test packages/coding-agent/test/acp-builtins.test.ts -t usage, but this worktree failed before tests with missing ./tool-views.generated.js.
Thanks for the focused cleanup.

[roboomp]

blocking: ?? limit.scope.accountId / ?? limit.scope.projectId runs before the type and empty-string guard, so invalid metadata suppresses a valid scoped fallback. Example: metadata.accountId === "" with limit.scope.accountId === "acct-1" makes line 1347 produce "", line 1348 reject it, and the renderer falls through to projectId/account N instead of acct-1. The PR body says empty metadata falls through to scope.accountId/scope.projectId; guard the metadata value first, then fall back to limit.scope.*.

[oldschoola]

Fixed in latest push. Empty-string metadata values now fall through to the scope fallback instead of suppressing it.

[oldschoola]

Addressed blocking review in latest push (6d25917):

The ?? operator doesn't help when metadata.accountId === "" (empty string is not null/undefined, so it suppresses the scope fallback). Now the metadata value is checked for truthiness first, then falls back to limit.scope.accountId/limit.scope.projectId:

const metaAccountId = report.metadata?.accountId;
const accountId = typeof metaAccountId === string && metaAccountId ? metaAccountId : limit.scope.accountId;