feat(ci): add bitbucket-pipelines.yml

[pablovilas]

Adds bitbucket-pipelines.yml, implementing the nullplatform CI contract
(np build start -> build -> np asset push -> np build update) on Bitbucket Pipelines.

Templates ship every provider's CI file at once and each SCM only reads its own path, so this
file is inert on GitHub, GitLab and Azure DevOps. No existing CI file is modified.

No Bitbucket marketplace app and no custom pipe are required. Unlike the Azure DevOps
integration (which needs a published extension for the NullplatformParameter@0 task),
Bitbucket lets a step name any public image directly, and public.ecr.aws/nullplatform/np-cli:kaniko
already ships /np and /kaniko/executor. Nothing new to build, publish or install.

Failure reporting

Bitbucket has no if: always() and no when: on_failure. A failed build is reported from
after-script, which always runs and is the only place BITBUCKET_EXIT_CODE is defined.

Note the spelling: Bitbucket uses after-script (hyphen); GitLab uses after_script
(underscore). Bitbucket silently ignores unknown keys, so the underscore spelling would mean the
failure path never runs — failed builds would hang in in_progress forever while the pipeline
looked green.

Verification

The pipeline shape was proven end-to-end against the real platform before this PR: a Bitbucket
push produced a green nullplatform build (successful, with a docker-image asset, repository
URL / branch / commit all auto-inferred), and the after-script BITBUCKET_EXIT_CODE guard was
observed firing on a failing step.

This file was additionally validated locally: it parses, its multi-line commands fold into the
intended single shell commands, and the full CI contract (start -> asset push -> successful, plus
the failure guard) is asserted mechanically.

Depends on

• Enabling Pipelines on the repository + injecting the secured NULLPLATFORM_API_KEY repository
  variable at provisioning time (workflow-manager). Pipelines is off by default — a
  bitbucket-pipelines.yml in a repo with Pipelines disabled is completely inert: no run, no
  error, no UI hint.
• np CLI Bitbucket repository-URL inference (AutoInferBuildFlags).

[pablovilas]

⚠️ Merge order: this is blocked on the CLI fix being RELEASED, not merely merged.

This pipeline installs np from cli.nullplatform.com/install.sh (or the np-cli image), which serves the released CLI. The released np does not yet auto-infer Bitbucket build flags, so np build start fails here with:

error: 'missing required flags: repository, branch, commit-sha, commit-permalink, description'

That failure was reproduced live on a real Bitbucket pipeline before the fix.

The fix is nullplatform/cli#196. Please do not merge this until that lands and ships in a release (and, for the kaniko templates, until public.ecr.aws/nullplatform/np-cli is rebuilt).

Verified live once the patched CLI is in place: a Bitbucket push produces a green nullplatform build with a docker asset — both the kaniko shape and the make + docker-service shape.