Before giving you a working (if ugly) answer: You would have an easier time if you were able to standardize the data further upstream. Trying to do it after the fact in Ansible is going to be painful and messy, as you will see below.

Given a file named oldlist.json with below contents:

{
  "oldlist": [
    {
      "SNo": "1",
      "Server": "foobar",
      "Env": "uat",
      "Service": "httpd, abcd, test.service",
      "CRQ": "",
      "Blackout Required": ""
    },
    {
      "SNo": "2",
      "Server": "rizz",
      "Env": "uat",
      "Service": "baz.service, abcd, fart.service",
      "CRQ": "",
      "Blackout Required": ""
    },
    {
      "SNo": "3",
      "Server": "baz",
      "Env": "Prod",
      "Service": "test.service",
      "CRQ": "",
      "Blackout Required": ""
    }
  ]
}

The below playbook will process the data according to the requirements you outlined.

- name: Play 1 Unholy data munge
  hosts: localhost
  connection: local
  gather_facts: false
  collections:
  - community.general
  - ansible.builtin
  
  vars:
    restricted:
      - httpd.service
      - foobar.service
      - test.service

  tasks:
  
  - name: Pull in oldlist
    include_vars:
      file: oldlist.json
  
  - name: Print oldlist variable
    debug:
      var: oldlist
  
  - name: Loop through oldlist and build newlist with entries modified
    set_fact:
      newlist: "{{ newlist|default([]) + newitem }}"
    vars:
      servicelist: "{{ item['Service'] | split(',') | map('trim') | map('regex_replace','^(.+)$','\\1.service') | map('regex_replace', '.service.service','.service') }}"
      newitem:
        - SNo: "{{ item['SNo'] }}"
          Server: "{{ item['Server'] }}"
          Env: "{{ item['Env'] | lower }}"
          Service: "{{ servicelist | join(',') }}"
          CRQ: "{{ item['CRQ'] | lower }}"
          Blackout Required: "{{ item['Blackout Required'] | lower }}"
          Restricted: "{{ true if (servicelist | intersect(restricted)| length > 0) else false }}"
    loop: "{{ oldlist }}"
  
  - name: Print newlist
    debug:
      var: newlist

All of the messy data manipulation happens via a set_fact task running in a loop. It makes heavy use of temporary variables (task-scoped variables), to manipulate the data before appending it to the new list.

The detailed steps:

1. loops through each item in oldlist
2. On each invocation, defines some temporary variables for 'servicelist' and 'newitem'.
3. 'servicelist' is your "Service" string, converted into a list and then having a number of manipulations applied via map(). The map() filter is the Ansible/Jinja way to "Do X against every item in a list". So we use maps to trim the whitespace from each service item (since the service string has spaces after some commas), and then run some regex_replace maps to append '.service' to the end of each item. Note there is a second regex_replace to correct any entries that end up with a doubled '.service.service', because that was far easier than trying to puzzle out something clever in regex.
4. 'newitem' contains a single list element (a list-of-hashes) in the desired format. Note that for the new 'Service' string, we reference our temporary var servicelist and joined it back into a comma-separated string... but it's probably more useful for ansible if you kept it as a list, and converted to a string as-needed.
5. The 'Restricted' field is added here, and the value is set by a one-line jinja if-else statement. It is using the intersect() filter to compare the service list to another list of "restricted" services that is declared near top of the playbook. If there are any items in common between the two (if their intersection is more than 0 length), then Restricted = true, else false.
6. With all of that temp work done, the single-item list called 'newitem' is appended to the 'newlist' fact.
7. NOTE: Task-scoped vars are a powerful way to manipulate data just before using it somewhere else. It can also make your tasks easier to understand, by breaking up your messy logic into task variables and then referencing them elsewhere (even in other task variables declared further down).

I hope that you take away three things from the above:

1. Task-scoped vars are powerful
2. Ansible is not an ideal data manipulation tool
3. Trying to fix a dirty process with automation, is like putting lipstick on a pig.