ci(data-deploy): forward favicon + description to relaton index

[andrew2net]

Adds the two missing workflow_call inputs so relaton-data-* repos can restore
the per-flavor branding lost in the Jekyll → relaton index migration.

Why

relaton/relaton#96 (merged) added --favicon and --description to
relaton index, but this workflow does not expose them — its inputs are only
source, title, data-dir, mode, relaton-cli-version, relaton-repo,
relaton-ref. Callers cannot work around that: passing an undeclared input to a
reusable workflow is a hard parse error (Invalid input, 'favicon' is not defined in the referenced workflow), so relaton-data-w3c is blocked on this.

Each data repo's deleted _config.yml carried a favicon and a description
blurb; title survived the migration, these two did not. This is the last
missing link.

What

• Two optional workflow_call inputs, favicon and description, both
  type: string, both default: "".
• Both flags passed unconditionally in both build steps (gem source and
  git source). No conditional flag construction is needed: relaton-cli runs
  presence(options[:favicon]) / presence(options[:description])
  (index_site_generator.rb:54-55, with a comment noting this exists precisely
  because a workflow renders an unset input as --favicon ""). Callers that
  pass nothing get byte-identical output to today.
• The values travel by env: and are referenced as "$FAVICON" rather than
  inlined as ${{ inputs.favicon }}. They are free-form prose, and ${{ }} is
  substituted as raw text before bash parses the line — an inlined description
  reading IEC "TC 1" registry would word-split into stray argv entries.
• Header comment notes the optional branding inputs (it previously said only
  "Callers need no changes").

Spec refresh

spec/data_deploy_workflow_spec.rb still guarded the Jekyll build that #58
removed (BUNDLE_GEMFILE → Gemfile.deploy, bundle exec jekyll build), so it
was already failing on main. It now guards the current caller contract:
every input optional, the two branding inputs declared with the load-bearing
empty default, exactly two build steps (one per source mode), and every one of
--title / --favicon / --description / --base-url present in both —
those near-duplicate command lines are the real drift risk.

Verification

• bundle exec rake → 179 examples, 0 failures.
• Verified against relaton@a7dc4f2a0 that --favicon / --description are
  plain string options on relaton index (relaton-cli/lib/relaton/cli/command.rb:149-153).
• Building the real relaton-data-w3c corpus (17,184 YAML docs) with those flags
  produced the expected <meta name="description"> and
  <link rel="icon" ... type="image/svg+xml">; passing "" for both produced
  neither tag.

Release gate (unchanged)

gem mode still cannot work — no published relaton-cli has index at all.
Repos piloting with source: git (currently relaton-data-w3c) build from
relaton/relaton@main and already have #96, so they pick up branding the moment
this merges, with no gem release needed.

Follow-ups (pre-existing, not in this PR)

Review of the surrounding file flagged some things landed in #58, listed here so
they are not lost:

• Top-level permissions: contents: read zeroes pages: for build_index_page,
  which still runs actions/configure-pages@v4. Worth checking whether that
  action needs pages: write — note its base_path output is no longer consumed
  now that --baseurl is gone, so dropping the step may be simpler.
• title="${{ inputs.title }}" in Derive title has the same quoting hole fixed
  here for the new inputs, and echo "title=$title" >> "$GITHUB_OUTPUT" is not
  multiline-safe.
• The derived title uppercases the repo slug (RFCSUBSERIES Index,
  CALCONNECT Index), regressing the display: names in data-index/configs.yml.
• spec/gemfile_deploy_spec.rb and the Gemfile.deploy Cimas mapping still
  enforce a Jekyll bundle nothing consumes.