Individual Responsibility and Individual Time Management

Do these members of the team not own individual tasks that they estimate. 

Nope. All work on a Sprint Backlog is owned jointly by a Scrum Development Team, even when particular members might agree to action certain items.

There is a lot in your post. I'll try to give you my opinions on as much as I can.

Scrum does not guarantee that every member of the team will be busy for the entire Sprint.  It doesn't even guarantee that your team will be more productive.  The point is to deliver incremental value on a consistent basis. In the example you mentioned, it appears that you have a cross-functional team but it also sounds like they are not willing to do anything other than "their job".  In theory a cross functional team would be willing to help with work that is outside of their specialty.  Your team may not be full stack but I would guess that your backend developer could help test the front end while it is being developed. 

You are correct that you do not want anyone "moving on to other work" unless the entire Development Team has included it in the Sprint Backlog.  Encourage the team members to spend idle time in the Product Backlog refining stories.  Refinement does not have to occur in a meeting.  Becoming familiar with and asking the Product Owner clarifying questions is exactly what refinement is all about. 

Do these members of the team not own individual tasks that they estimate. Would you not own that task/code and estimate that item so you can track the developer skill at time estimation or is this counter-intuitive to the team approach? 

Where in the Scrum Guide do you see anything about "time estimation"?  The time is managed by the time box used for your Sprint. There is no need to "track the developer skill at time estimation".  It sounds like your Development Team has found a scale to use in their estimation that works for them.  But I highly suggest that you don't start trying to correlate hours to that estimate.  Estimates are used to help gauge the relative size of one story to another.  It can be useful to a team to gauge the estimated amount of work that they are pulling into a sprint as it relates to previous sprints.  But in no case are you guaranteed that the 8 point story you pulled into 2 sprints ago is going to be equal to the 8 point story you pull into your next sprint.  Estimates are guesses based on the information you have available at the time you make the estimate.  Empiricism shows that you will most likely learn more that could affect the work effort positively or negatively. Do not micro-manage the time a developer is "busy".  There is a lot of work that a developer can do that isn't writing code.  Most developers will fight that because they do not feel like they are doing anything if they aren't writing code.  As Scrum Master help them understand how other work can be of benefit to the team, the company and to their own career growth.

Yes it is counter intuitive to the team approach to manage individual time.  A Scrum Team agrees to deliver an increment of value in each Sprint.  The Product Owner is responsible for making sure that the problem being solved is well known. As new information is discovered in the process of building, there will be need for clarification.  The Scrum Master is responsible for helping the entire Scrum Team be more productive and to improve team cohesion. The Development Team is responsible for ensuring that they technology used is the best choice and implemented in the most effective way.  None of this says that it ensures that any of them are working all 8 hours of the day. 

In Scrum you focus on the delivery of value in a potentially releasable increment in every sprint.  The Product Owner will decide if there is enough value to actually release based on a wide variety of reasons (enough functionality, market able to accept a release, etc). It is best not to focus on developers being busy writing code at all times. 

As to documents you must read I have nothing specific to give you.  I suggest you read a lot on self-managing teams. Read everything you can find on scrum.org and scrumalliance.org as they are both lead by the two founders of Scrum and the information available on those sights are vetted to be correct.  Read information on how Kanban measures team capacity and throughput.  Become familiar with the concepts of Lean as they can help with understanding how idle time can be utilized productively.  Read the Scrum Guide frequently.  I read it at least one a week and it seems that I uncover something new every time because my experience grows. Be wary of things you read on other blogs and websites as they are often opinions or interpretations from the individuals and can be misunderstood. 

Good luck with your journey.  It sounds like you have a good start and the desire to learn more which is vital in this line of work.