Table Partitioning - database file increased after partitioning
In this instance rather than messing with the complexity of partitioning I'd either:

Just move the entire DB over to the drive with more space.
Detach the DB, move the files over and reattach.
See https://docs.microsoft.com/en-us/sql/relational-databases/databases/detach-a-database and the other related sections.
Or backup, drop original, and resore with the files on the other drive.
Create a new datafile as you have done, but instead of partitioning tables, just move whole tables and indexes over to the new file group like so:

    CREATE CLUSTERED INDEX PK_MY_TABLE
    ON my_schema.my_table(DATE ASC, ID ASC)
    WITH (DROP_EXISTING = ON, ONLINE = ON)
    ON MY_FILEGROUP

In either case I would undo the partitioning first as it would not be needed, and for paranoia's sake take regular manual backups during the process.
With regard to partitioning, note that all your examples above have done is move the data (the clustered index) for rows one side of your partitioning function. The data for non-clustered indexes will still all be in the original filegroup unless you partition those also. This may explain not as much data moving over as you expected.
Note that is also applies to moving tables between filegroups without partitioning: the non-clustered indexes need to be moved explicitly also, or they will stay where they are. In fact having the indexes in another filegroup to the table will work just fine so you don't have to move them, or you could move then instead of the main table data (the clustered index or heap) and leave that where it is.
Freeing Space
Once all this is done, which ever way you do it (partitioning or moving while tables/indexes to a new filegroup), the file(s) making up your primary filegroup will not automatically shrink to release space to the OS, you will need to do this as an extra step afterwards.