…4857)

The previous README getting used to give me an error.

```bash
(base) ~ ❯❯❯ bacalhau docker run ubuntu echo Hello World              
Error: server is not running or not reachable at http://127.0.0.1:1234
Hint:  to resolve this, either:
1. Ensure that the server is running and reachable at http://127.0.0.1:1234
2. Update the configuration to use a different host and port using:
   a. The '--api-host=<new_address> --api-port=<new_port>' flags with your command
   b. The '-c API.Host=<new_host> -c API.Port=<new_port>' flags with your command
   c. Set the host in a configuration file with 'bacalhau config set API.Host=<new_address>' and port with 'bacalhau config set API.Port=<new_port>'
3. If you are trying to reach the demo network, use '--api-host=bootstrap.demo.bacalhau.org' to call the network
```

I think I corrected it

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

- **Documentation**
- Updated the quickstart guide with an enhanced command for job
submission, now including options to specify a service host, wait for
job completion, and use an updated Docker image for improved execution.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Co-authored-by: Walid Baruni <wdbaruni@gmail.com>

)

## Overview
This PR addresses a specific issue with platform compatibility
verification for Docker images that are already cached locally. The fix
ensures that Bacalhau properly verifies platform compatibility before
using locally available Docker images.

## Problem
We identified a specific issue in our Docker image handling logic:

When a Docker image is already pulled and available in the local cache:
- The system was using the locally cached image without properly
verifying if its platform is compatible with the host platform
- This could lead to execution failures when the locally cached image
was built for a different architecture than the host
- For example, if an arm64 image was cached on an amd64 host, the system
would incorrectly attempt to use the incompatible image

This issue only occurred when incompatible images were already present
in the local Docker cache. The remote registry verification was working
correctly when no local image was available.

## Solution
This PR implements a targeted fix:

- Enhanced the `isPlatformCompatible` check to properly verify locally
cached images against the host platform
- Added proper handling to fall back to pulling from the remote registry
when a locally cached image has an incompatible platform
- Improved logging to clearly indicate when a platform mismatch is
detected with locally cached images

## How to Reproduce the Issue
The issue can be reproduced with these steps:

```bash
# On an arm64 host machine:

# Pre: Remove the image from your local cache if it exists
docker image rm ubuntu:latest

# 1. Pull an amd64 image to local cache
docker pull --platform linux/amd64 ubuntu:latest

# 2. Run a Bacalhau job with Docker executor
bacalhau docker run ubuntu:latest -- echo "hello world"

# Result: Before the fix, Bacalhau would attempt to use the locally cached amd64 image 
# on the arm64 host, potentially causing execution issues
```

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

- **New Features**
- Enhanced image compatibility checks to ensure that only container
images matching the host environment are used.
  
- **Chores**
- Optimized the platform information caching interval, reducing it from
24 hours to 1 hour for fresher data.
- Improved error handling to better manage and report issues when
platform details are incomplete.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Currently when users submit a job without specifying a count, it's not
clear what happens:
- Batch/service jobs silently fail to run as count defaults to 0, which
means no executions are needed.
- Users have to debug why their job isn't executing
- No indication that count needs to be set

This change makes it more intuitive:
- Batch/service jobs default to count=1 if not specified
- Explicit count=0 is still respected (useful for stopping jobs)
- No changes to daemon/ops jobs which run on all matching nodes

This should reduce confusion and make job submission more user-friendly,
especially
for new users trying out the system.

### Examples
Job will run and default to count=1
```
Type: batch
Tasks:
  - Name: main
    Engine:
      Type: docker
      Params:
        Image: ubuntu
        Parameters:
          - echo
          - hello
```

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

- **New Features**
- Enhanced job submission logic with improved handling of the count
field, setting default and validation rules based on job types.

- **Documentation**
- Updated API and Swagger documentation to clearly describe how the
count field behaves for different job scenarios.

- **Tests**
- Expanded test coverage with descriptive cases to verify proper
handling, normalization, and validation of the count field.
  - Improved error message assertions for invalid field types in tests.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

The current behaviour in bacalhau is that networking in disabled by
default in jobs and in compute nodes. Users would have to opt-in for
networking by setting `JobAdmissionControl.AcceptNetworkedJobs` config
to true. This has caused lots of confusion as jobs that require
networking would fail without a clear reason.

This PR is a first step towards making networking enabled by default in
both compute node admission control and in job spec, and making
networking opt-out instead of opt-in.

The PR just introduces the new opt-out config
`JobAdmissionControl.RejectNetworkedJobs` to allow users to reject
networking today and prepare for the change when networking is enabled
by default in v1.7

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

- **New Features**
- Introduced a new configuration option that enables users to reject
jobs requiring network access, providing finer control over job
admission.
  
- **Documentation**
- Updated API and configuration descriptions to reflect the new
rejection-based approach, with notifications that the legacy acceptance
option will be deprecated in future releases.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->