Use adjusted calorie goal for summary and per meal targets

[gPinato]

Description

What problem does this PR solve?

The Diary page shows inconsistent calorie and macro goals: the Daily Energy Goal widget displays the TDEE-adjusted value but the Nutrition Summary and per-meal targets (Breakfast, Lunch, Dinner, Snacks) still use the raw stored goal. This makes the page contradict itself when Adaptive TDEE or goal mode adjustments are active.

How did you implement the solution?

The server already computes adjusted goals internally via goalService.getUserGoals(..., true) but never exposed them in the API response. This PR adds an adjustedGoals field (nullable) to the daily summary response containing the adjusted calories and macros. The web and mobile frontends use this field to display consistent targets across all diary components.

How to Test

1. Set calorie goal adjustment mode to Adaptive TDEE in Settings → Calculation Settings
2. Ensure sufficient weight + intake data for Adaptive TDEE to compute (28 days)
3. Navigate to the Diary page
4. Verify the Nutrition Summary calorie goal matches the Daily Energy Goal widget
5. Verify per-meal targets (Breakfast, Lunch, Dinner, Snacks) sum to the adjusted total
6. Verify protein, carbs, and fat goals are scaled proportionally
7. Switch to a non-adaptive mode (e.g. Fixed) and confirm everything reverts to raw stored goals

PR Type

• Issue (bug fix)
• New Feature
• Refactor
• Documentation

Checklist

All PRs:

• [MANDATORY - ALL] Integrity & License: I certify this is my own work, free of malicious code, and I agree to the License terms.

New features only:

• [] [MANDATORY for new feature] Alignment: I have raised a GitHub issue and it was reviewed/approved by maintainers or it was approved on Discord.

Frontend changes (SparkyFitnessFrontend/):

• [MANDATORY for Frontend changes] Quality: I have run pnpm run validate and it passes.
• [MANDATORY for Frontend changes] Translations: I have only updated the English (en) translation file.

Backend changes (SparkyFitnessServer/):

• [MANDATORY for Backend changes] Code Quality: I have run typecheck, lint, and tests. New files use TypeScript, new endpoints have Zod schemas, and new endpoints include tests.
• [MANDATORY for Backend changes] Database Security: I have updated rls_policies.sql for any new user-specific tables.

UI changes (components, screens, pages):

• [MANDATORY for UI changes] Screenshots: I have attached Before/After screenshots below.

Mobile changes (SparkyFitnessMobile/):

• [MANDATORY for Mobile changes] Tested on device or emulator: I have verified the changes work on iOS or Android.

Notes for Reviewers

• adjustedGoals is a nullable field on the existing /daily-summary response — no new endpoints or DB changes
• The field is null when raw and adjusted goals are identical (no adjustment active) — fully backward-compatible
• The server leverages the existing goalService.getUserGoals(..., true) call that was already being made — we just compare it against the raw call and expose the difference to clients
• The web frontend calls useDailySummary from Diary.tsx which hits the react-query cache (DailyProgress already fetches it) — no extra network request
• 2 new unit tests cover: null when no adjustment, and correct values when goalService returns different adjusted goals

[github-actions]

PR Validation Results

Change Detection

• 🖥️ Frontend changes detected
• ⚙️ Backend changes detected
• 📱 Mobile changes detected

⚠️ Recommendations (1)

• Please link a related GitHub issue (Linked Issue: Closes #123).

✅ All required checks passed.

[gemini-code-assist]

Code Review

This pull request introduces support for adjusted nutritional goals across the web frontend, mobile app, and backend server. It fetches and applies adjustedGoals when they differ from raw goals, ensuring that users see dynamically adjusted targets. The review feedback highlights a few key issues: the mobile hook extracts adjustedGoals but fails to use them in the top-level calorie calculations; the web frontend does not include the loading state of the daily summary hook in its page loading check, potentially causing layout shifts; and the backend service uses any types and complex parsing logic that can be simplified for better type safety.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.