Host contact form status icons

[mugdhchauhan]

Closes #716

What changes did you make?

• Show dynamic status icons (✓⃝ complete, ◐ partial, ◯ incomplete) to indicate the completion state of the Contact Info section in the Host Profile.

Rationale behind the changes?

• To accurately reflect user progress for the contact info section using clear status icons

Testing done for these changes

• Followed Testing Strategy and Acceptance Criteria as mentioned in Dev: Display Host Contact Information Form Progress #716

What did you learn or can share that is new?(optional)

• Gained practical experience in implementing backend status evaluation logic and integrating it with frontend visual indicators.
• Learned how to design FastAPI routes that return computed statuses based on database values.
• Became familiar with how to conditionally update records in the database based on user_id rather than creating duplicate entries.
• Improved understanding of maintaining alignment between frontend and backend validation rules for consistent user experience.
• Learned how to work with optional fields in SQLAlchemy and Pydantic, including making fields like phone_number nullable.
• Acquired familiarity with using a dedicated status endpoint (/completion-status/{user_id}) to drive frontend UI feedback logic.

Screenshots of Proposed Changes Of The Website (if any, please do not screen shot code changes)

Visuals before changes are applied

Visuals after changes are applied

Screenshots.pdf

[tylerthome]

This looks great, based on everything we discussed this meets exactly what we wanted out of this effort.

A couple of pending items for our discussion this week:

• Styling - let's get in sync with design here, and where it makes sense we can make some styling configs more dynamic and possibly integrated with Figma(etc) tooling
• Using string values for responses as opposed to strict identifiers
• Navigation based on form step - comment in PR

Thanks for the great work here @mugdhchauhan !

[tylerthome]

Let's revisit this soon to decide precisely the behavior we want, and if the ! operator meets our needs (as opposed to a more explicit handling of the condition where linkedFields is null

[tylerthome]

This could be a good place for an enum to leverage TypeScript to the benefit of code readability, TBD pending discussion, not a blocker for this task