[Correctness] Guard checks normalized length, but the backend rejects on raw length - the guard leaks a 422 for whitespace-padded inputs

This isGoalObjectiveTooLong measures normalizeGoalObjective(objective).length, and getGoalObjectiveCounter does the same. But the backend's binding rejection is on the raw objective length, not the normalized one:

• ThreadGoalRequest.objective: str = Field(..., max_length=4000) (backend/app/gateway/routers/threads.py:323) - pydantic validates the raw string length and returns 422 before the endpoint body runs.
• normalize_goal_objective (backend/packages/harness/deerflow/runtime/goal.py:108) re-checks the normalized length, but normalization only ever shrinks the string, so that second check is redundant - the binding constraint is the pydantic max_length on the raw field.

And the frontend sends the objective raw (input-box.tsx: JSON.stringify({ objective: command.objective })), where parseGoalCommand trims leading/trailing whitespace but preserves interior whitespace.

Repro: /goal + "a" x2000 + 4 spaces + "a" x1999

• command.objective = 4003 raw chars (interior spaces preserved)
• Client guard: normalized = 4000 -> 4000 > 4000 = false -> no toast, PUT sent
• Counter shows 4000/4000 (green, non-destructive) -> user thinks they're within the limit
• Backend: pydantic max_length=4000 on the 4003-char raw string -> 422 - the exact raw error this PR aims to eliminate

This is realistic on paste (multi-line goals with blank lines / indentation, or runs of spaces between words). The PR's own test "counts collapsed whitespace like the backend, avoiding false rejections" (the interiorAtLimit case) asserts this allowance as correct - but the backend would 422 that input, so the test encodes the bug.

Fix: mirror the backend's actual binding constraint - check command.objective.length > MAX_GOAL_OBJECTIVE_CHARS (already leading/trailing-trimmed by parseGoalCommand) and have the counter display command.objective.length. The normalizeGoalObjective mirroring should be dropped here: the backend does not apply it before the pydantic check, so applying it client-side is what opens the hole. (If normalization is kept, then the objective must be normalized before the PUT body too, and the guard/counter measure the normalized value - but that double-normalizes against the backend's own normalize_goal_objective, so the raw-length check is cleaner.)

The guard and the counter need to use the same measure the backend enforces, or the green counter actively misleads the user into submitting inputs that 422. Note: MAX_GOAL_OBJECTIVE_CHARS = 4000 itself matches the backend (runtime/goal.py:37), so it's only the normalization-before-check that's off.