Add Schedules page and enhance report builder with period presets

[jfrench9]

Summary

This PR introduces a new Schedules management page under the ledger section and enhances the report builder with period preset functionality. It also includes a dependency update and minor code quality improvements.

Changes

New Features

• Schedules Page (/ledger/schedules): Added a full-featured schedules management interface with a new content component (~548 lines) and corresponding page entry point. The schedules page is now accessible via the sidebar navigation.
• Period Presets in Report Builder: Extended the report creation flow (/reports/new) with period presets functionality, significantly expanding the report builder content (~347 lines of additions/modifications). This allows users to quickly select common date ranges when building reports.

Improvements

• Report Description Formatting: Enhanced how report descriptions are displayed in the report detail view (/reports/[id]/content.tsx) for improved clarity and readability.
• Code Readability: Refactored period preset return statements for cleaner, more maintainable code.
• Sidebar Navigation: Updated sidebar-config.tsx to include the new Schedules page link.

Dependency Updates

• Updated @robosystems/client from previous version to 0.2.44 — this may provide API support required by the new schedules functionality.

Housekeeping

• Removed exports from src/lib/core/index.ts (9 lines deleted) as part of a module split/reorganization referenced in commit 797b6c4.

Breaking Changes

• src/lib/core/index.ts: Exports have been removed from this barrel file. Any internal imports relying on re-exports from @/lib/core should be verified. Downstream consumers of these exports may need to update their import paths.
• The @robosystems/client upgrade to 0.2.44 may introduce API changes — confirm compatibility with existing API call sites.

Testing Notes

Reviewers should verify:

1. Schedules Page
   • Navigate to /ledger/schedules and confirm the page loads correctly
   • Verify CRUD operations (create, read, update, delete) for schedules if applicable
   • Confirm the sidebar link appears in the correct position and navigates properly
2. Report Builder Period Presets
   • Navigate to /reports/new and verify period preset options are displayed
   • Test each preset to ensure correct date range population
   • Confirm custom date selection still works alongside presets
3. Report Detail View
   • Open an existing report at /reports/[id] and verify description formatting renders correctly
4. Regression
   • Ensure existing report functionality is not broken by the refactored code
   • Verify no broken imports after the lib/core module reorganization

Browser Compatibility Considerations

• The new schedules page adds a substantial UI component (~548 lines) — verify layout and interactions across Chrome, Firefox, Safari, and Edge
• Test responsive behavior on mobile/tablet viewports, especially for the schedules content and the expanded report builder form
• If the schedules page uses any date pickers or complex form controls, verify cross-browser input behavior
• No new browser APIs or CSS features are expected based on the change scope, but the large UI additions warrant visual QA across browsers

---

🤖 Generated with Claude Code

Branch Info:

• Source: feature/schedules
• Target: main
• Type: feature

Co-Authored-By: Claude noreply@anthropic.com

[jfrench9]

@claude please review this PR

[claude]

Claude finished @jfrench9's task in 1m 45s —— View job

---

PR Review

• Read changed files
• Review schedules page (content.tsx, page.tsx)
• Review report builder changes (reports/new/content.tsx)
• Review report detail view changes (reports/[id]/content.tsx)
• Review sidebar config and core library changes
• Post final review

---

Overall this is a well-structured PR. The new schedules page is clean, follows existing patterns, and the period presets in the report builder are a useful UX addition. A few issues worth addressing before merge:

---

Issues

1. Dead code: unused formatCurrency function
src/app/(app)/ledger/schedules/content.tsx:49-54

formatCurrency (which divides by 100, treating input as cents) is defined but never called — only formatCurrencyDollars is used throughout the file. Either remove it or it may signal a currency unit inconsistency in the API data. Worth verifying whether the API returns cents or dollars.

Fix this →

---

2. Bug: underscore replacement only affects first match
src/app/(app)/ledger/schedules/content.tsx:492

String(schedule.scheduleMetadata.method).replace('_', ' ')

.replace(string, ...) only replaces the first occurrence. A method like straight_line_depreciation would render as straight line_depreciation. Use .replaceAll('_', ' ') or replace(/_/g, ' ').

Fix this →

---

3. Accessibility: missing label for period-end date input
src/app/(app)/ledger/schedules/content.tsx:193-197

The period-start input has id="period-start" with a matching htmlFor label, but the period-end input has neither id nor aria-label. Screen readers won't be able to identify it.

Fix this →

---

4. Fragile auto-map polling with hardcoded timeout
src/app/(app)/reports/new/content.tsx:354-366

setTimeout(async () => {
  // refresh coverage after 5s
}, 5000)

If the AI mapping takes longer than 5 seconds (likely for larger CoAs), the coverage won't reflect the result and isAutoMapping will be cleared prematurely, leaving the user with stale data and no indication that the job is still running. The app already has task monitoring infrastructure — consider using useOperation / useTaskMonitoring from core, or at minimum a polling loop. As-is, a simple UX improvement would be to keep isAutoMapping true until the user manually refreshes, or show a "Mapping in progress" badge.

---

5. annual_comparison preset uses future year-end date
src/app/(app)/reports/new/content.tsx:213-231

{ start: `${year}-01-01`, end: `${year}-12-31`, label: `FY ${year}` }

If today is April 2026, the current year period ends Dec 31, 2026 — a future date. This may be intentional (for a full fiscal year budget view), but it could produce empty/incomplete results and surprise users who expect it to cover only YTD. Consider whether the end date should be capped at today for the current year, or add a clarifying description like "Full calendar year (may include future months)".

---

6. createClosingEntry called with periodEnd twice
src/app/(app)/ledger/schedules/content.tsx:132-137

await extensions.ledger.createClosingEntry(
  graphId,
  structureId,
  periodEnd,   // 3rd arg — "as of" date?
  periodStart,
  periodEnd    // 5th arg — period end
)

periodEnd appears as both the 3rd and 5th argument. Verify this matches the API signature — if the 3rd argument is an "effective date" that should match a different value, this could silently create entries with the wrong date.

---

Minor Notes

• reports/[id]/content.tsx:297 — The description prop has complex inline template logic. It's functionally correct but could be extracted to a variable for readability.
• FactsModal key uniqueness (content.tsx:341) — Key ${fact.elementId}_${fact.periodStart} could collide if the same element appears twice in a period. Using the outer loop index as part of the key would be safer.
• src/lib/core/index.ts — Removing FileClient, MaterializationClient, TableClient, useTableUpload, and related types is a breaking change for any consumers of this barrel. The PR description calls this out, but ensure the other RoboSystems apps (robosystems-app, roboinvestor-app) have also been updated or that this removal is coordinated with the core subtree push.

---

What Looks Good

• Period preset logic in buildPresetPeriods is correct and handles edge cases well (January YTD, Q1 prior-quarter, year-end rollover).
• The schedules page cleanly separates concerns into PeriodClosePanel, FactsModal, and SchedulesContent.
• Dark mode and responsive classes are applied consistently throughout.
• The formatDate helper correctly appends T00:00:00 to avoid timezone-shifted dates.
• Sidebar config follows the established getNavigationItems pattern.